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 
That’s an urban myth.
But it is true that “Tiddler” (fish) lingo is somewhat at odds with a kitty logo :-).
I think it happenstance.
If you go to the bottom of Mill Lane, Barrow-Upon-Soar, Leicestershire, UK and dangle your feet in the water around the Old Mill tiddlers will happily nibble your feet.
Is now an opportunity to minify the core by splitting out some parts and make them into plugins preinstalled with the standard distro?
I can think of a few “semi bells and whistles” but a prime example would be the drawing tool. If TW had not already had one, and it was proposed as a feature today, I’d guess it would be added as a plugin (right?)
Some features are of a nature that they help you accomplish or create something at a specific occasion but, after that, they’re no longer needed. If such features have a significiant enough footprint, maybe a guiding idea for the core is to feature them as plugins?
An appealing aspect with plugins (perhaps especially, concrete items like “the drawing tool”) is that it invites for experimenting with - and developing - alternatives. Speaketh a plugin maker; It is psychologically easier to create alternative plugins than it is to create things that mess with the core and overwrite stuff. It is also practically easier to investigate something that is properly split out, e.g to see how it interfaces with the core.
Thoughts?
Anything logical.
Over time ‘core’ has grown.
IMO @jeremyruston needs decide
QED
