[TW2036] Planning for v5.4.0

#82

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.

#83

@JanJo check this

Screenshot_20250606-162004
Screenshot_20250606-1620041080×1793 180 KB

2 Likes
#84

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)

2 Likes
#85

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:

2 Likes
#86

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. .

#87

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.

#88

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 ;- )

#89

Nice! I will try that.

#90

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.

#91

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 “*”

#92

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.

#93

It would of they where separated. All of them are list.

#94

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.

  • Handling where | 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.

  • By providing methods or defacto standards to support these tiddlywiki from a meta perspective is like turbocharged hackability because a designer can directly interogate TiddlyWikimarkup and script directly.
  • It would be great if for example designers had access to the parsing logic already in TiddlyWiki for rendering wiki text.
    • Eg: the same rules that identify wikitext symbols.
#95

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.