Ste_W
March 24, 2026, 11:29am
1
Again, this is probably a problem my end, BUT, in 5.3.8 with the sidebar closed this tiddler applies a style and looks like this:
Using the tufte slightly tweaked stylesheets provided by
@Mohammad .
A straight upgrade and the tree graph thing dosn’t pop out to the side.
The tufte demo tiddler (see link at the end of this) does all the pop out to the side things in both old and new TW, so I’m sure it’s a me problem, but just thought I’d raise it.
Link to problem tiddler and tufte related tiddlers
It looks like it’s not picking up the macro/widget/ procedure/ magic
pmario
March 24, 2026, 6:21pm
2
@Ste_W I can replicate the problem, with the following steps
→ <<tidgraph macro is not rendered properly
cc: @jeremyruston @saqimtiaz
pmario
March 24, 2026, 7:11pm
3
@Ste_W I did change <<tidgraph"{{$:/Force Graph}}">> to <<tidgraph "{{$:/Force Graph}}">>
See the space in front of "{{$:/Force … It seems to work well now.
@jeremyruston … I did create an issue at GitHub which describes the problem in more detail.
I am not sure if the “space” check was intentional or just an oversight.
2 Likes
Ste_W
March 25, 2026, 12:11am
4
Thanks for looking into this.
TwN00b
March 30, 2026, 12:39am
5
Just tried the pre-release - my tiddly is super custom - and has not had any issues upgrading - - until this version.
Before:
After:
Don’t know what I need to submit - specifically - and unsure how to extract my personal data - before submitting,…
I can see at least one issue:
In the “after” output, it shows the code for
<$action-sendmessage $message="tm-new-tiddler" title=<<now"YYYY-0MM-0DD">> ...
Note that the <<now>> macro does not have a space between the now macro name and the "YYYY-0MM-0DD" parameter value. This problem was reported here:
Again, this is probably a problem my end, BUT, in 5.3.8 with the sidebar closed this tiddler applies a style and looks like this: [image]
Using the tufte slightly tweaked stylesheets provided by @Mohammad .
A straight upgrade and the tree graph thing dosn’t pop out to the side.
The tufte demo tiddler (see link at the end of this) does all the pop out to the side things in both old and new TW, so I’m sure it’s a me problem, but just thought I’d raise it.
Link to problem tiddler and tufte rela…
and a GitHub ticket was created 5 days ago:
opened 07:09PM - 24 Mar 26 UTC
closed 12:25PM - 28 Mar 26 UTC
bug
**Macro invocation without space before first parameter fails in v5.4.0 prerelea… se**
### Summary
Macro invocations that omit the space between the macro name and the first quoted parameter no longer parse. This is a backward-incompatible regression introduced by the new `parseMacroInvocationAsTransclusion()` function in PR #9055.
### Steps to Reproduce
Create a tiddler with the following content:
```
\define greet(name)
Hello, $name$!
\end
No space (broken): <<greet"World">>
With space (works): <<greet "World">>
```
**Expected result**: Both lines render `Hello, World!`
**Actual result**: The first line produces no output. The second line works correctly.
This also affects quoted parameters with other quoting styles:
```
\define show(text)
Result: $text$
\end
<<show"hello">>
<<show'hello'>>
<<show[[hello]]>>
```
All three fail silently — none of them render — because the parser rejects the macro invocation when there is no whitespace between the macro name and the first parameter.
### Root Cause
In [`core/modules/parsers/parseutils.js` line 241](https://github.com/TiddlyWiki/TiddlyWiki5/blob/master/core/modules/parsers/parseutils.js#L241), the new `parseMacroInvocationAsTransclusion()` function has a strict check that was not present in the old `parseMacroInvocation()`:
```javascript
// Check that the tag is terminated by a space or >>
if(!$tw.utils.parseWhiteSpace(source,pos) && !(source.charAt(pos) === ">" && source.charAt(pos + 1) === ">") ) {
return null;
}
```
This requires that the character immediately after the macro name is either **whitespace** or **`>>`**. Any other character (including `"`, `'`, `[`, `` ` ``) causes the entire macro invocation to be rejected.
### Trace for `<<greet"World">>`
1. `<<` is consumed, `pos` advances past it
2. `reVarName = /([^\s>"'=:]+)/g` matches `greet`, stops at `"` (which is in the excluded character set)
3. **Line 241 check**: `parseWhiteSpace()` returns `null` (not whitespace), and `"` is not `>>` → **returns `null`**, entire parse fails
### Why the old parser worked
The old [`parseMacroInvocation()`](https://github.com/TiddlyWiki/TiddlyWiki5/blob/master/core/modules/parsers/parseutils.js#L418) (line 418) has **no such check**. After capturing the macro name, it passes directly to `parseMacroParameters()` → `parseMacroParameter()`, which calls `skipWhiteSpace()` internally (tolerating zero whitespace) and then matches the quoted string `"World"` via its regex.
### Additional context
The new `reVarName` regex (`/([^\s>"'=:]+)/g`) also differs from the old `reMacroName` regex (`/([^\s>"'=]+)/y`) by additionally excluding `:` from the macro name. This means macro names containing `:` (which were valid before) are now truncated at the colon, compounding the stricter post-name check.
### Impact
This is a **silent failure** — no error is produced, the macro simply doesn't render. Any 3rd party plugin or user wiki that uses the `<<macroname"param">>` syntax (no space) will break on upgrade to v5.4.0 without any diagnostic message.
### Affected Versions
- **Introduced in**: PR #9055 (commit 6bc77cf3e, Feb 4, 2026) — "Dynamic parameters for macro/procedure/function calls"
- **Affected function**: `parseMacroInvocationAsTransclusion()` in `core/modules/parsers/parseutils.js`
- **Not affected**: The old `parseMacroInvocation()` (line 418) still exists and does not have this check
However, 2 days ago it was marked as “completed” but NOT “fixed” because, as explained by @jeremyruston
it is an edge case that has only been reported when it was encountered due to an error.
You have two possible responses:
Add a comment to the GitHub ticket explaining why leaving this unfixed will cause you lots of problems
Go through your TiddlyWiki and manually fix each instance of “missing a space after the macro name”
-e
1 Like
TwN00b
March 30, 2026, 3:36am
7
Thanks @EricShulman - - I added a note to the ticket.
Thank you everyone. I’ve pushed an update that restores the ability to omit the whitespace after the variable name.
master ← restore-compact-call-syntax
opened 12:15PM - 01 Apr 26 UTC
The compact call syntax omits the usual space after the target name: `<<thing"pa… ram">>`. This syntax was broken in #9695, but as reported [here](https://talk.tiddlywiki.org/t/v5-4-0-prerelease-compact-macro-call-causes-an-issue/15091) at least some users depended upon it.
The fix here is actually straightforward. The existing code checks for a space after the variable name. We want to widen the check to instead to check for a space or any of the valid parameter quoting parameters. The regex `([^\s>"'=:]+)` that is used to parse variable names already assures that the variable is terminated by the same characters, and so we can entirely omit the redundant check.
2 Likes
