You know what, I had searched for almost exactly this before, but couldn’t find anything like it.
However I wonder: with his/her amount of knowledge, would* it not be so easy to use the same template as the regular editor?
edit: By, “would it not” I mean literally perhaps “should it not” be that easy. If it were that easy, then the plugin would probably not have to re-do it for instance. It’s more of a thought about the core for the sake of enabling the community in this regard.
You mean an instance of any use for each of the UNused System tags does not exist in Empty?
Yes?
Taggery in TW is a triple: brilliant, fundamental, and ultra-flexy.
TAG MANAGER
My suggest here is to Enhance The Tag Manager to give it easier powers to … Create Tag Tiddlers for any unused System Tag. And give more options on tag manipulation in general. Should not add much code?
IMO the Tag Manager is underused and with a bit of love could live up to it’s name and become a major way to understand and improve one’s own wikis.
TT
My personal solution to missing system tags is a small package that list all system tags known to tiddlywiki, that I have collected in an additional sidebar > more tab. However I also use my Reimagin tags package that adds a lot of additional features to the tag pill dropdown.
The Question is what should move into the core, however none of these are breaking backwards compatibility.
A thing that could be fixed in 5.4 would be implementing the option to close modals by a click outside them.
What happens if an older version wiki that has Relink installed as third party plugin will get updated to 5.4.0? Will it be a matter of going to Plugins tiddler, remove Relink and reinstall it from the core plugin library?
In my book, Relink is a strong contender for that one plugin that gets installed first into an empty wiki, and besides it being extremely functionally useful to end users (it does automatically what would be a scary wikitext programming task), if bringing it into the core will also yield speed improvements, I’ll be two times happier, because renaming tiddlers in a 10+MB wiki on a 5 years old smartphone introduces a noticeable lag while typing in the tiddler tittle text field, a lag that is big enough to break the fluidity of working with the wiki.
huh, I’d had the same desire for modals and had missed this in the doco originally.
tbh, having this set as a field in the content for the modal feels pretty backwards to me. I expected a per-modal setting to be something set as a parameter to the call of the modal, but more generally, it’s a setting I’d want to be global to the wiki, for consistency (and then be able to toggle to the alternative on a per-modal basis)
We need to get v5.3.7 released before we can properly start merging PRs for v5.4.0. I’ve made a GitHub ticket to collect any suggestions for PRs or fixes that should be included:
Thank you @arunnbabu81 I had missed this.
I also would like the setting to be more general - or to have it set to true by default.
I think there are only some usecases where I might want the user to Click“accept“ explicitly. .
Speaking of modals, having the title of the tiddler in the modal header as a link would also be nice. I am resorting to having <$link>*</$link> be a part of every new tiddler in case I want to open it from a modal.
You could put this into the subtitle-field. I think this is a smart solution - but sometimes on the contrary, I supress the modal title in order to have more space in the modal itself.
I think it would be usefull to have no title at all if there is no subtitle-field. Having a systemtiddeler title displayed there is only distracting for users. (BTW is there a different word for the non-admin and non-programmer users - e.g. the students that just read the texts - Sometimes it would be usefull to have it to think them as an entity ;- )
Nice! I will try that.
I think it is possible to warn if the relink plugin is now redundant if upgrading to a version where the features have being moved into the core. Regarless all that becomes nessasary is to remove the plugin.
There is a proposal at GH
[Proposal] Every List-like wikitext rules shuold be 1 module. That makes it easy to disable them selectively
Since it would be a backwards incompatibility as Saq Imtiaz posted at GH it should be considered for v5.4.0
Crossposted from GitHub
Every List-like wikitext rules shuold be 1 module. That makes it easy to disable them selectively
From GG:
3 - Is a godsend where you to need switch off pragma because of use case. Why? Example: probably the worst pragma to switch-off is the Block Parse Rule for “list” because it disables ALL forms of list construct (*#:;). Example use case: Wiki concerned with posting to social networks where “#” is used all the time you need to switch of processing of “#”. …
Proposal
The /parser/list.js module should be splitted into 4:
- list-bullet.js
- list-hash.js
- list-definition.js
- list-blockquote.js
This will allow users to disable them 1 by 1 in the Control Panel. … It will probably duplicate some code. … BUT I think it would be worth the convenience. At the moment diabling the “list” rule disables 4 different elements, where 2 of them are really important “>” and “*”
Just for clarity is it not sufficent to use ControlPanel > Advanced > Parsing to alter the state of each seperate parsing rule?
From memory there is also pragma that allows to to selectivly enable/disable rules as well so I dont think there is much reason to introduce such a compatibility break.
It would of they where separated. All of them are list.
Jeremy,
In a related discussion here Using links[] in current tiddler we discovered the value of handling | delimited pairs initialy to parse out pretty|title from [[pretty|title]]and |tblecol|tablecol| so I wonder if a more general solution can be found for other.
| is also found inside shortcut transclusions say to extract a template name etc… could also benifit.Note:
The features we are discussing here are in someways tiddlywiki script meta issues, ie pertaining to manipulating wikitext as found, making solutions that directly interogate wiki text or text field contents (Before render) rather than simply TiddlyWiki Script and filter operators.
For 5.4.0?
I dont know if it would be a break but could we have a less complex version of the keyboard driven macro or some reusable code to make such methods easier to use?
Similarly a builder for any facility that requires multi-tiddlers to implement such as shortcuts, view and editor toolbar buttons etc… these demand too much cognative load for many uses to benefit from them.
In version 5.4.0 we can complete the image conversion for TiddlyWiki. It was discussed before, but maybe it can be finalised for 5.4.0. Which may also require AI for creation. Here are some links to related discussions.
Updated, my thought is that maybe we could use brand new animal images, or any other images for that matter. Because the cat itself has nothing to do with the connotations expressed by TiddlyWiki. Of course continuing to use the cat is ok. It’s just that I was a bit confused before, is the cat used to catch fish, to show that we are catching the idea.
Again, update, I think the cheetah is a good option if a new animal icon is used, as there are times when I see the kitten as a cheetah.
fyi a tiddler is a small fish in English I believe, cat like catching them 