Dynamically modifying core tiddlers

56 views
Skip to first unread message

damscal

unread,
Feb 26, 2022, 7:02:21 AM2/26/22
to TiddlyWiki
Use case: I'm trying to overwrite a few core tiddlers to introduce a cascade filter mechanism (similar to the ones implemented in $:/core/ui/TagTemplate to set the tag icon and colour) to allow flexible customization of tags text labels. In particular, to allow displaying different fields other than the default title field in tag labels (reason: sometimes tiddler titles get too long).

Question: would I be forced to manually check and merge changes at every update of the TW core, or are there more efficient ways?
I'd like to set up a system that automatically overwrites small sections of the core so that I wouldn't need to merge changes manually, perhaps coupled with an alert/log system that notifies me of situations requiring user supervision.

Thank you all,
Dam

damscal

unread,
Feb 26, 2022, 7:09:33 AM2/26/22
to TiddlyWiki
Edit: I have tried to develop this use case without modifying the core (through CSS styling), but it seemed unfeasible when working with tag pills.

PMario

unread,
Feb 27, 2022, 10:33:26 AM2/27/22
to TiddlyWiki
Hi,
If you would be a bit more specific, what you want to do exactly, it may be possible to provide some pointers. ... May be your ideas are also suitable to improve the core UI in a generic way. .. If so .. It may be possible to implement some new stuff directly into the core. .
-mario

Jeremy Ruston

unread,
Feb 27, 2022, 10:49:45 AM2/27/22
to TiddlyWiki
Hi damscal

It's a good idea. The best way forward might be to propose a core change to introduce an additional cascade for the template used to display the content of a tag pill, so that users can have tags with custom appearances.

But to answer your question directly, there is no standardised way to modify core templates without breaking subsequent upgrades. We try to introduce mechanisms for common use cases to avoid modifying templates directly, but it's still the last resort for people wanting to do particularly intricate customisations.

Best wishes

Jeremy

damscal

unread,
Mar 6, 2022, 10:21:52 AM3/6/22
to TiddlyWiki
Thank you very much Mario and Jeremy. I have proposed the additional cascade on github, hopefully it can be implemented in one of the future upgrades.

Coming back to the main topic, is there a standard way to reference/transclude a shadow tiddler that was replaced by a standard tiddler?
This would make possible overwriting a shadow tiddler with a standard tiddler that is dynamically derived from the shadow itself, even after a plugin upgrade.

Example:
  1. user overwrites the shadow $:/plugin/some-tiddler with a standard tiddler of the same title
  2. the original shadow tiddler can be accessed/referenced  with the title $:/plugin/some-tiddler/overwritten (or an equivalent way)
  3. the user can write wikitext inside $:/plugin/some-tiddler which references $:/plugin/some-tiddler/overwritten , e.g. through something like {{{ [{$:/plugin/some-tiddler/overwritten}search-replace["text to replace"],["replace with this"]] }}}
  4. when there is a plugin upgrade,  $:/plugin/some-tiddler/overwritten gets automatically updated. If the new version is different, a log reminds the user to review the diff to check that things aren't broken.
  5. if the plugin upgrade makes the customisation obsolete, the user can simply delete  $:/plugin/some-tiddler
Thank you all,
Dam

damscal

unread,
Mar 6, 2022, 11:10:42 AM3/6/22
to TiddlyWiki
Well, I've just seen that accessing the original shadows is possible using the subtiddler attribute of the set widget. If there are also other ways, please let me know. Automatizing the alert and diff log could be an idea for a plugin, if there are none already doing the same thing.
Thank you,
dam

Jeremy Ruston

unread,
Mar 7, 2022, 9:10:51 AM3/7/22
to tiddl...@googlegroups.com
Hi dam
Well, I've just seen that accessing the original shadows is possible using the subtiddler attribute of the set widget. If there are also other ways, please let me know. Automatizing the alert and diff log could be an idea for a plugin, if there are none already doing the same thing.

You can also access subtiddlers directly with the view and transclude widgets. There's also a "subtiddlerfields" filter operator for reading the names of fields within a subtiddler.

Best wishes

Jeremy

Thank you,
dam

On Sunday, March 6, 2022 at 4:21:52 PM UTC+1 damscal wrote:
Thank you very much Mario and Jeremy. I have proposed the additional cascade on github, hopefully it can be implemented in one of the future upgrades.

Coming back to the main topic, is there a standard way to reference/transclude a shadow tiddler that was replaced by a standard tiddler?
This would make possible overwriting a shadow tiddler with a standard tiddler that is dynamically derived from the shadow itself, even after a plugin upgrade.

Example:
  1. user overwrites the shadow $:/plugin/some-tiddler with a standard tiddler of the same title
  2. the original shadow tiddler can be accessed/referenced  with the title $:/plugin/some-tiddler/overwritten (or an equivalent way)
  3. the user can write wikitext inside $:/plugin/some-tiddler which references $:/plugin/some-tiddler/overwritten , e.g. through something like {{{ [{$:/plugin/some-tiddler/overwritten}search-replace["text to replace"],["replace with this"]] }}}
  4. when there is a plugin upgrade,  $:/plugin/some-tiddler/overwritten gets automatically updated. If the new version is different, a log reminds the user to review the diff to check that things aren't broken.
  5. if the plugin upgrade makes the customisation obsolete, the user can simply delete  $:/plugin/some-tiddler
Thank you all,
Dam

On Sunday, February 27, 2022 at 4:49:45 PM UTC+1 jeremy...@gmail.com wrote:
Hi damscal

It's a good idea. The best way forward might be to propose a core change to introduce an additional cascade for the template used to display the content of a tag pill, so that users can have tags with custom appearances.

But to answer your question directly, there is no standardised way to modify core templates without breaking subsequent upgrades. We try to introduce mechanisms for common use cases to avoid modifying templates directly, but it's still the last resort for people wanting to do particularly intricate customisations.

Best wishes

Jeremy

On Sunday, February 27, 2022 at 3:33:26 PM UTC PMario wrote:
Hi,
If you would be a bit more specific, what you want to do exactly, it may be possible to provide some pointers. ... May be your ideas are also suitable to improve the core UI in a generic way. .. If so .. It may be possible to implement some new stuff directly into the core. .
-mario

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c9a24c52-f8f5-4626-bada-b7909fa0c8a4n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages