[BUG] Updating info tiddlers using the callback sets the dirty flag

[Rhys-T]

Describe the bug

If a module of type info calls the updateInfoPlugin callback it's given after the wiki is up and running, it causes the wiki to be marked as dirty/unsaved (the save button turns red, etc.). This happens even if updateInfoPlugin is passed an empty array, and isn't actually changing anything.

Expected behavior

I expected the wiki to not become dirty when info tiddlers change, since they aren't saved anyway as far as I can tell. The fact that the info pseudo-plugin is prefixed with $:/temp/ seems to indicate that this shouldn't count as a 'real' change.

To Reproduce

1. Download a blank TiddlyWiki.
2. Import this tiddler: https://gist.github.com/Rhys-T/5080ac9b27af73bff9fe370687087472
3. Save the wiki and reload.
4. Wait 5 seconds. The save button will turn red.

Screenshots

No response

TiddlyWiki Configuration

• Version: 5.3.6
• Saving mechanism: Timimi
• Plugins installed: none

Desktop:

• OS: macOS
• Browser: Firefox
• Version: macOS 10.15.7, Firefox 134.0.1

Smartphone:

Not yet tested.

Additional context

This seems to happen because updating $:/temp/info-plugin causes it to be re-unpacked, which counts as a change to every tiddler inside it - including the default $:/info/* ones, which are included in the default $:/config/SaverFilter. Adding -[prefix[$:/info/]] to the end of $:/config/SaverFilter seems to stop the info plugin from dirtying the wiki, but it was a quick test, and I don't know whether changing that has any problematic side effects or not.

[pmario]

I think you are right with your issue description. But I am not really sure, what you try to achieve.

Can you be a bit more specific?

---

As you can see at: https://tiddlywiki.com/dev/#Startup%20Modules.svg the info modules are executed way before the tiddler "change" detection is active.

The 5 second delay in your code is the problem here. So if you want to change the $:/Info tiddlers, you will have to modify them at startup.

You can have a closer look, how I did it with the palette-watch plugin

Have a closer look at dark-light-change.js info module.

If you create your own plugin, you will have to make sure, that you also check for $tw.browser otherwise your plugin will cause problems with the Node.js server.

Hope that gives you some hints.

[pmario]

Somewhat related PRs. In 8555 draft Jeremy creates a general purpose "background" event catcher that can be used by users. 7830 was my first attempt to implement dark / light theme detection as a core plugin.

• Introduce background actions and media query tracker mechanisms #8555
• add browser dark/light theme detection #7830

[Rhys-T]

The 5-second delay was just a stand-in for any event that might cause a module to call the updateInfoPlugin callback¹ again after startup time. However, it turns out you can actually see an example of this without adding any custom modules at all:

1. Download and open a blank TiddlyWiki.
2. Without editing the wiki at all, toggle the browser's prefers-color-scheme between dark and light mode.
3. $:/core/modules/info/platform.js will use the callback to update $:/info/darkmode. (That seems to be the only info tiddler which that module ever updates after startup.)
4. The wiki's dirty flag will be set.

---

The particular module I was trying to write is actually something of an abuse of the info system: I was trying to generate several related palettes² from a common template, and since there's no way for a palette to do transclusions and such before it gets treated as a dictionary - to copy a block of items from a 'common' tiddler, for example - I was creating the palettes as info tiddlers so I could auto-regenerate them as I was working. Kind of a weird example, and definitely not how the info system is meant to be used, but it basically worked. The only problem is that every time I saved the 'common' tiddler, the wiki would immediately become dirty again even though it had just been saved. Still, like I said, this affects the one built-in info module too.

Footnotes

1. Which I accidentally just called update in my example module. $:/core/modules/info/platform.js calls it updateInfoTiddlersCallback. ↩

2. Ports of the four flavors of Catppuccin. ↩

[pmario]

4. The wiki's dirty flag will be set.

That's exactly the point I wanted to make. As soon as the wiki is started, the store "change" mechanism is active. So whenever you activate the "callback", the dirty flag will be set.

There is no easy way to avoid this at the moment. The only way is to add changed tiddlers to $:/config/SaverFilter as you found out. The problem with $:/Info/ filters is, that we do not really know the side effects. -- As you wrote.

[pmario]

I was trying to generate several related palettes2 from a common template, and since there's no way for a palette to do transclusions and such before it gets treated as a dictionary

The palette handling is rewritten at the moment. See: #8702

So everything you do now with palette handling will be outdated, when this PR is active.

---

Ports of the four flavors of Catppuccin.

That's a very interesting project.

[Rhys-T]

That's exactly the point I wanted to make. As soon as the wiki is started, the store "change" mechanism is active. So whenever you activate the "callback", the dirty flag will be set.

There is no easy way to avoid this at the moment. The only way is to add changed tiddlers to $:/config/SaverFilter as you found out. The problem with $:/Info/ filters is, that we do not really know the side effects. -- As you wrote.

Yeah, that makes sense. I was just surprised because the info tiddlers were all shadows, and the info pseudo-plugin that's actually changing is under the $:/temp namespace.

The wiki I have the custom info module in is only being used to work on the palettes, so I wound up modifying its SaverFilter and hoping for the best. Haven't had any problems with that yet. The only other time I'm noticing the effects of this issue are in the morning, when my machine starts up, restores the browser session, switches back to light mode, and marks any other wikis I have open as unsaved when I haven't even had a chance to touch them.

The palette handling is rewritten at the moment. See: #8702

So everything you do now with palette handling will be outdated, when this PR is active.

Ah, interesting! Yeah, that definitely sounds like it will help with a lot of the stuff I'm currently having to work around (color math, places in the core that use color entries directly instead of wikifying them, etc.) I'll keep an eye on that, then. Thanks for pointing that out.