Dealing with changes to core tags macro

#1

Folks,

Has anyone done any work using the DiffTextWidget to identify, capture and distribute changes to a core tiddler? Even if the user needs to do this manually, it would allow each independent change to be applied independently, and reapplied if necessary.

Background example

There is a bit of work and discussions on updating the core tags macro, and tag pill, the fact is I have half a dozen changes to apply at least in my own wikis. I do not want to wait or perhaps dream that my changes would be incorporated.

My list of features, These include but are not limited to;

  • The ability to provide a label (rather than the tag name) for the tag pill.
    • This also permits a special feature I call virtual tags eg; <<tagging todo label>> in the subtitle presents a virtual tiddler for all tiddlers, in the tag pill drop down you can add the tag todo, to make it a todo item.
  • An optional condition filter field that determines if a tag will be displayed on the view template.
  • An optional Payload filter to alter what is included when dragging a pill to another wiki
  • An optional list-filter to alter what appears in the tag pill dropdown list eg on the todo tag rather than [tag[todo]] use [tag[todo]!tag[done]]

Now I would like to package these to share with the community and between my wikis, the thing is each edits the same two core tiddlers, $:/core/ui/TagTemplate and $:/core/macros/tag it would seem I need to package them in one and modify the core tiddlers in one hit.

Conclusion

As long as we have parts of the core that are regularly updated by plugins or solutions this approach is desirable over the alternatives. Hence my above Question.

#2

What you describe is called a “patch” of if there are more a patch-set. That’s the most maintenance intensive and error prone way to change core tiddlers.

The best way atm is to completely overwrite a core tiddler, so you can be sure it works. Even if some new functionality is lost. At least it still works “the old way”.

Even if the core tends to change slowly, it can happen that parts of the core are completely rewritten, as I did with all the documentation macros, that are now using v5.3.x syntax.

In the future this will happen until the whole core uses the latest syntax.

So a patch-set created with v5.2.x could be able to “match” parts of a v5.3.x tiddler and may even patch the new tiddler. But the chance is high that this will completely mess up the generated code. So neither the old code nor the new code will work.

I do not recommend to follow that rabbit hole.

#3

I did create 2 threads at Talk

This may help with experimenting.

1 Like
#4

The problem is we change it anyway to get the results we need, I would have thought if we are going to do that, we may as well be able to review and guide the application, of at least minor changes.

  • One approach is to replace Alice with Bob. If the code changes so drastically that Alice is not there we can indicate as such and not apply any change (just stirring @Scott_Sauyet :nerd_face: by using meta-syntactic variables )

I will review your references thanks @pmario

  • I did look at makepatches etc… in the past, I will revisit with fresh eyes. I just noticed I can use strings.
  • Also my thoughts would be a simple interface to assist, along with tools to review existing core tiddler changes, perhaps even take a snapshot of the modified core tiddler so we can also compare the current shadow, with the one we changed, there by detecting possible issues.
    • A Plugin or package could include the manual step(s) to apply changes to the core tiddler and become part of the installation instructions.
#5

You may be interested in @Yaisog’s Patches tool. Here’s the discussion thread: In-Wiki Incremental Revisions -- Now Even Better!

#6

But a patchfile can help with that too, showing precisely what changed last time you needed to do so. It can guide you in what you need to change this time, even if you cannot directly apply it as a patch.

#7

Just for clarity, I am sure patches can be divided into different types and depth of change. In the changes to core macros I am interested in, there is typically the insertions of a line or altering the values assigned to an attribute.

  • Rather than change a core tiddler we could even clone an existing definition like $:/core/macros/tag then set it so it’s macros “wins” in the order of precedence.
    • We then apply changes to this tiddler.
  • This allows one to switch back to the core by removing the global tag from the replacement tiddler.

However;

  • Now I have this hands off approach I would like a mechanism to apply one or more changes independently of each other. Using the aforementioned patches.

Imagination and innovation

  • It seems to me we just need to work through the needs and mechanisms available and find an acceptable approach.
  • If designed well we can make the existence of patches obvious, provide the tools to deactivate, reverse, reapply, even detect a change in the core/shadow.
  • Most of this can be automated but it is fine to include a manual review process if necessary. Lets not make "the perfect, the enemy of good”.
  • I can Imagin a tool for creating the patches
    • Copy tiddler to be changed and save in a package (archive of current core). Add the current Tiddlywiki version it came from.
    • Make the changes to the core shadow/now a tiddler
      • Possibly clone and modify
    • Compare with saved changes and generate patches
    • Package with tools to apply, reverse, compare, reapply, detect change of shadow and archive. Possibly even get an indicator if a patch is able to be applied.
    • We could even have a startup action if the tiddlywiki version changes to bring the change to the attention of the user if the core has changed relative to the archive copy, and direct a user to the patching package.
    • This would be a special patch package and brings its own tools, however many patches you install.

So here I solicit ideas for “Dealing with changes to core tags macro” and other key and hackable components.

1 Like