Discussion: Rather than overwrite core, override core, when you must

#1

Folks,

I mention @pmario and @jeremyruston as we have had related discussion in the past.

I am making some adjustments to my reimagine-tags solution as a result of the discussion here Italicize tag iff there's no tiddler there (tag itself is "missing") so if the tags tiddler does not exist the tag pill will show italics.

  • To do this I face the common dilemma that to make reimagine-tags to work I have to change the behaviour of a number of tag macros and its tag pill template $:/core/ui/TagTemplate
    • I realised since I have rewritten the tag macro that uses $:/core/ui/TagTemplate I can clone it to $:/PSaT/reimagine-tags/$:/core/ui/TagTemplate and change the reference to it.
    • Note my use of the core tiddler name but with the prefix of my package

Then I realised I can also avoid overwriting the tag macros by also cloning
$:/core/macros/tag to $:/PSaT/reimagine-tags/$:/core/macros/tag and making my changes.

  • Again Note my use of the core tiddler name but with the prefix of my package
  • Its best to set list-after to the macro tiddler it replaces, so the macro tags to be the last definition tiddlywiki uses from $:/tags/Macro, thus without changing the core macros tiddler I override the macros within it.

The point?

We still can face the issue of the fact more than one package may redefine the tag macros however the advantages of this approach are;

  • I don’t actually change core tiddlers with my solution, I don’t overwrite core tiddlers
  • My tiddlers that override the normal behaviour are more obvious because thier core tiddlers title is still in the name but with my packages prefix.
  • This allows me to indicate in my tiddlers the source tiddler ie the core tiddler name, and I have a custom preview that lets me preview the differences.
    • An advantage here is I am comparing my tiddler with the Current tiddlywiki core version.
  • If something else overrides the core macros I can
    • Review the differences
    • Restore my reimagine-tags version by overriding them again

Futures

It seem to me we could adopt a defacto standard to do this when making modifications to core tiddlers, which offers not only the above improvements and visibility of such changes but may also give us the possibility of one day creating a tool to apply changes to core tiddlers from multiple packages, manually if not semi-automated.

Final note;

We should always push changes to the core that allow hackability of core tiddlers without redefining them and permit multiple solutions to implement changes without touching the core

  • For example tags without a tag tiddler showing italics in the tag pill is best moved to the core, so I dont need to include it in my package.

but when we do touch the core this approach is I believe superior.

#2

I agree with your approach and do the same, but the only difference I am curious about is that I will often clone the core tiddler, change the prefix from $:/core/... to $:/wiki/... for example, and have the list-after field value be the title of the original core tiddler, so that if any tiddlers were to come after it, my modification would not disturb the future tiddlers. Atleast in theory.

I do wish this were possible with all tiddlers, such as some of the JavaScript tiddlers, but otherwise, being that it is recommended to not change the core tiddlers, this seems like the only viable alternative, no?

1 Like
#3

@Justin_H

Its nice to know others were thinking along the same lines.

I have subtly changed the post to add your better approach of list-after tiddler you are overriding.

Although there is some value using a prefix like $:/wiki it is also a good idea to establish a “brand prefix”, I use $:/PSaT which stands for my People, Systems and Things brand.

2 Likes
#4

The idea seems to be interesting.

Do you have a JSON bundle that we can drag to tiddlywiki.com and test it?

#5

I also use a similar technique. I thought it was pretty much the standard. I know I learned it in these forums, but don’t remember from whom.

I rename from $:/core/macros/... to $:/my/project/core/macros... (without duplicating the $:/). But otherwise it’s much the same.

#6

I will prepare an example however this is a multi-faceted proposal is there particular things you want demonstrated?

To me a full solution would include the following

  • a package that minimizes overwriting the core and instead overrides
  • using the core tiddler titles you overide in the package
    • override tiddler contain a tiddler-source field containing a title of the core tiddler
  • the provision of a preview in the editor that allows you to compare the package tiddler differences with the current code tiddler perhaps also the shadow.
  • possible buttons to apply or reverse changes from those in the package. Or a configuration option?

@pmario thanks for pushing that change to the tags macro for missing tag tiddlers.

All, lets keep the discussion moving.

What other opportunities do you see for changes in practices to make such issues easier to manage?