Your help is needed to test v5.4.0

Pre-release documentation for Calls says:

Calls can be used in filters. The text is not wikified which again means that the parameters will be ignored.

Testing using <<now>> macro with : vs = param handling:

<$let fmt="YYYY0MM0DD0hh0mm0ss0XXX">

#literal unnamed param<br><<now YYYY0MM0DD0hh0mm0ss0XXX>>
#literal named param using `:`<br><<now format:'YYYY0MM0DD0hh0mm0ss0XXX'>>
#variable named param using `=`<br><<now format=<<fmt>>>>
#filter with unnamed param<br><$list filter="[<now YYYY0MM0DD0hh0mm0ss0XXX>]"><<currentTiddler>></$list>
#filter with literal named param using `:`<br><$list filter="[<now format:'YYYY0MM0DD0hh0mm0ss0XXX'>]"><<currentTiddler>></$list>
#filter with variable named param using `=`<br><$list filter="[<now format=<<fmt>>>]"><<currentTiddler>></$list>

produces this output:

literal unnamed param
20260224084305886
literal named param using :
20260224084305886
variable named param using =
20260224084305886
filter with unnamed param
20260224084305886
filter with literal named param using :
20260224084305886
filter with variable named param using =
Filter error: Missing [ in filter expression

Thus, calls in filters using the unnamed param or : literal named param syntax still work, even though Calls seems to say otherwise.

Multi-valued variables clarification: do filter operators each have to be individually updated in order to support MVVs?

The MVV docs say “Certain filter operators can accept multi-valued parameters: function Operator, title Operator”. Does that mean that these are the only operators that will understand MVVs, and everything else treats them as single values?

(If so, that severely limits their possibilities…)

2 posts were split to a new topic: V5.4.0 prerelease - Simple Search Plugin Seems to Have a Problem

2 posts were split to a new topic: V.5.4.0 prerelease - link-to-tabs Plugin Link Icon has Wrong Colour

3 posts were split to a new topic: V5.4.0 prerelease - Several block-quote syntax blocks are slow

Most operators operate on input and don’t make much use of parameters. Only parameters need special support for handling MVV. Which operators did you have in mind which you want to pass MVV as parameter?

A few notes I’ve found running the updater against my wiki. 5.4.0 RSOEs my wiki currently:

  • the “Vis” plugin from @Flibbles’s graph plugin complains when updating a wiki (but I can’t reproduce in the sample for that plugin):
[Error] Script error.
	(anonymous function) (upgrade-4.html:5208)
	(anonymous function) (upgrade-4.html:5260)
	(anonymous function) ($:/plugins/flibbles/vis-network/vis.js:39)
  • Maybe related, or unrelated, but I hit an error in the transclusion widget immediately after:
[Error] ReferenceError: Can't find variable: alt
	(anonymous function) ($:/core/modules/widgets/transclude.js:462)
	(anonymous function) ($:/core/modules/widgets/widget.js:691)
	(anonymous function) ($:/core/modules/widgets/element.js:83)
	(anonymous function) ($:/core/modules/widgets/widget.js:691)
	(anonymous function) ($:/core/modules/widgets/widget.js:72)
	(anonymous function) ($:/core/modules/startup/render.js:72)
	(anonymous function) ($:/core/modules/startup/render.js:74)
	(anonymous function) (upgrade-4.html:7640)
	(anonymous function) (upgrade-4.html:7587)
	(anonymous function) (upgrade-4.html:7597)
	(anonymous function) (upgrade-4.html:7777)
	(anonymous function) (upgrade-4.html:6782)
	(anonymous function) (upgrade-4.html:7775)
	_boot (upgrade-4.html:7784)
	Global Code (upgrade-4.html:7796)

I’ll see if I can get a minimal reproducing case for this (this is a private wiki).

2 posts were split to a new topic: V5.4.0 prerelease - Quick Image Plugin causes EditTemplate Problem

3 posts were split to a new topic: V5.4.0 prerelease - Markdown plugin causes RSOD

If by any chance you use the markdown plugin, this error about the alt variable may be related to an issue I just patched.

Aha. Well, if the parameters are what need to be manually updated, then that explains why the operators I tried weren’t working, because they were all in the format of operator(var)! Doing some quick testing now shows that yes, ones that don’t require parameters (like uppercase[]) are working as I expect them to.

(My initial test was a nested jsondexes & jsonget combo, which I thought should work fine because Jeremy had used jsonget in examples for his initial MVV presentation. Didn’t work, a jsonget(var1),(var2),[text] treated them as single values. My “sanity checks” of addsuffix(var) / addprefix(var) failed likewise. Guess I know why now…)

5 posts were split to a new topic: V5.4.0 prerelease - Performance Regression Using List Filters in ViewTemplate

Can we talk about Relink for a second?

I’ve just frozen the current version of Relink to TiddlyWiki <=v5.3.8. There are too many finnicky changes to wikiparsing for me to put in the time making Relink compatible pre and post v5.4.0.

But since I’m doing that, it means Relink might take advantage of new TW mechanics. But I’ve got some questions about it. I don’t have time to upgrade Relink just yet, but I’m looking at the core code now, and it doesn’t look like it’s in good enough shape yet for a new and improved relink—the kind you all deserve.

“Core plugin to serialize syntax trees back to strings”

This would be great… if it’s done right. Relink goes to a lot of trouble making its own wikiparser hybrids because it could never rely on converting to a parse tree and back.

It’s looking like this feature is only good for when the parse tree is exactly the same as it was. I’m seeing a lot of “start” and “end” stuff. But those get pretty useless to me quickly if Relink needs to 1) swap out a title with one of a different length, 2) change quotation on some attribute, or 3) downgrade a wikilink into a transclusion or something like that. Everything will get offset.

Is tracking offset just something I’ll need to contend with?

It doesn’t look like the parse tree remembers the kinds of quotes used. When you guys are “reverting” parse trees back into text, are you changing all the quotes the user chose to use? Or are you looking at the offsets?

Bulkops has not changed in 4 years.

One thing people have always disliked about Relink is that it uses startup modules to inject new code into bulkops—the wikimethod module that introduces the core relinking behavior for tags and list.

Relink does this because there is no other mechanism to do so properly. So Relink will still be blasting parts of bulkops and making itself incompatible with any other plugins that might want to introduce their own renaming behavior independent of Relink.

Is this fine with everyone? Or do we want to update this?

\Define and $depth

These two “features” are the two reasons Relink can never truly be a 100% relink solution. \define makes the wikitext too unpredictable. And $depth makes it impossible to know where parameters are coming from, and thus if they should be relinked.

\define is an old dog whose served us well, and I also know it probably can’t be removed yet. But $depth… ohhh. I’ve got bones to pick with that attribute

I know @jeremyruston agreed to deprecate it, at least for the <$parameters> widget (<$slot> doesn’t have a better alternative yet). Can we do that? Can we remove this monstrosity? I stand by my assertion that no one is using it, because no one knows how. It’s a terrible antipattern.

Edit: Sorry to everyone I’m bothering by asking. I know a lot of these questions are ones I could answer myself if I dug into the source more, but I’m in the middle of an unrelated time-constrained project, and might not have time to really jump into Relink again until after v5.4 releases.

9 Likes

Hi @Flibbles

My first reaction is that we should be prepared to delay v5.4.0 until these issues are resolved. Breaking a community plugin that so many people depend on is the last thing we want.

The points that you make are solid:

  • That the serialization mechanism doesn’t preserve the type of quotes should be regarded as a bug
  • Maintenance is made more difficult by keeping the serializing code apart from the parsing code. I believe that it was me that suggested keeping the serializer code in a plugin. The motivation was to be able to mark the plugin as experimental so that we could continue to refine it
  • Updating the bulkops implementation as you suggest seems reasonable
  • The deprecation of <$depth> is not currently documented. A crude GitHub search suggests that usage of <$depth> is not zero, but is very low
  • Again, the deprecation of \define is not currently reflected in the documentation

The primary policy decision is which of those issuesΩ need to be addressed before the release of v5.4.0. For example, the bulkops issue might be regarded as something we can defer because it is an internal refactoring. The counter argument would be that if we’re going to try to fix these issues then we should do so properly.

It looks like the bulk of the remedial work would be refactoring and re-engineering to integrate some or all of the functionality of the serializer plugin into the core. Do you have thoughts about how to approach the refactoring of bulkops? (Update: apologies I hadn’t seen your PR).

It’s good to bring these questions to a wider audience because the policy issues that it raises need discussion in the community.

4 Likes

A quick hello to everyone — I am actually just an end user, but I noticed something that, while not functionally relevant, still caught my eye.
I think there is a small inconsistency in the error output for recursive transclusion between the transclusion methods used. Only Lorem {{TiddlerTitle!!text}} behaves as expected and like in older versions (< 5.3.0), showing a preview (after the first save) and an output of Lorem Recursive transclusion error in transclude widget, while all the other methods make the entire text around the recursive construction disappear and only output the error: Recursive transclusion error in transclude widget.

Functionally this does not change anything, but I would prefer to always see the text (in preview and output) as in Tiddler2.

TITLE – TEXT – PREVIEW – OUTPUT ⇒ COMMENT
Tiddler1 – Lorem {{Tiddler1}} – Lorem errorerror ⇒ text output only in preview
Tiddler2 – Lorem {{Tiddler2!!text}} – Lorem error – Lorem error ⇒ as expected
Tiddler3 – Lorem {{}} – errorerror ⇒ without any text output
Tiddler4 – Lorem <$transclude /> – errorerror ⇒ without any text output
Tiddler5 – Lorem <$transclude tiddler=“Tiddler5” /> – Lorem errorerror ⇒ text output only in preview

all the best
Geron

1 Like

Excellent work from everyone involved. I checked my wiki with the 5.4.0-prerelease and everything appears to be working so far. The only thing I’ve noticed is a minor cosmetic change, which is SVGs wrapped in hyperlink <a> tags now don’t honor a color: inherit rule … I poked around in the inspector but couldn’t locate any specific new rule that was overriding this.

5.4.0

5.3.8

Something else I am noticing is that the zoom state of various Geospatial Utilities plugins (where I am tagging locations attached to specific tiddlers) is lost after upgrade

5.4.0

5.3.8 (preferred)

1 Like

The current value is tracked by the state tiddler declared using <$geomap state="...". Usually, this tiddler has a prefix of $:/state/. By default, when you use the TiddlyWiki upgrader, $:/state tiddlers are not included in the upgrade (they are unchecked). To retain the state tiddlers, you need to specifically select their checkboxes before pressing the “upgrade” button.

-e

2 Likes

and for NodeJS upgrade procedure is it the same ?

2 posts were split to a new topic: V5.4.0 prerelease - RSOD cause by dynaview