What would you do with a core tiddler conflict like this?

[Scott_Sauyet]

@TW_Tones

With the example of the icon field containing wiki text it is importiant to note its current and inherited functionality, is quite specific. It must contain a tiddler title of an icon tiddler. If you place anything else in this field it fails, Typicaly scilently.

• my argument would be rather than fail if and icon tiddler cant be found, treat it as wiki text and transclude it. This allows conditional content and unicode symbols.

But this means that every user of that icon field must understand this new behavior. The icon field is a long-established bit of content on TW; others besides me must be using it already for other purposes than showing it on tags and tiddler titles.

A wiki I’m currently working on for my day job actually uses the icon field to generate part of its own UI. If we change the content allowed on this long-standing field, my code may break when I update. I’m using the field directly, not through any core markup that might carry over on such a change.

This is not my scenario, but imagine the following: someone’s wiki does a short CSS animation of the content on loading of a tiddler. Part of that animation involves growing the icon from 0% size to 100% over two seconds. That works fine because we know that the icon field is either empty or has an image, whose width and height we can animate. If you allow arbitrary text in there, who knows what strange things it might do to their design?

I have been bitten by such things often enough in my career to be very wary of any data element designed to have more than one distinct usage. (And this from a developer who prefers dynamically typed languages!)

@TW_Tones

I understand your concern about “hooks” being large in number but on some ways this is a tiddlywiki principal to increase customisability especialy to the UI.

There is a real concern about resulting complexity, but I pretty much always end up on the side of more such hooks. It make for a much more flexible design, without forcing painful upgrades on users.

Thanks for raising this topic. It leads to some interesting dialogs!

[Scott_Sauyet]

@TW_Tones

have you encountered [conflicting overrides of core tiddlers]? and what tips and tricks do you employ.

I haven’t yet. But it makes me worry. It’s easy enough to see happening. I’m always happier using tools that use existing TW-provided hooks rather than overriding the core.

[TW_Tones]

@Scott_Sauyet

But this means that every user of that icon field must understand this new behavior. The icon field is a long-established bit of content on TW; others besides me must be using it already for other purposes than showing it on tags and tiddler titles.

I would argue not, only those who choose to change the icon field to wikitext. Even if you do change or provide a wikitext icon I believe (open to arguments to the contrary) there are few senarios, perhaps even yours. where there will be an undesirable result. You will observe there is no icon or at worst a single tiddler will have a funny icon.

• Because this is a per-tiddler only alternative.

@Scott_Sauyet

I haven’t yet. But it makes me worry. It’s easy enough to see happening. I’m always happier using tools that use existing TW-provided hooks rather than overriding the core.

• keep in mind many improvements to the tiddlywiki core tend to have their genesis in a plugin or package that overwrites one of more core tiddlers. Once the solution is acceptable only then should it move to the core.
• This is in fact how we identify that a new hook is required.

I do understand the issues of core changes, in this thread I was hoping to explore what to do when such clashes are experienced in the field. Unfortunatly we have not yet discussed this in much detail, although some inspiration can be found.

One solution I propose needs to overwrite at least one core tiddler, a second solution needs to override a second core tiddler. What are the options we can find?

• To deal with this “in the field”
• To assist when this inevitably happens in the future, before additional hackability is introduced or the core is “improved” ?

Here is some of my ideas to be an example but I did not share before to avoid prejudicing the discussion. Which does keep going off the rails.

When the change needs to me made to a macro ONLY

• We can define a macro with the same name that has the additional behaviours or ideally passes the operation through to the core macro otherwise.
• This is where the introduction of a new parameter is helpful because we can detect when it is in use. and when not just pass it through.

When the change needs to me made to a widget ONLY

• We can define a custom widget with the same name that has the additional behaviours or ideally passes the operation through to the core widget otherwise.

In otherwards if you get clashing modifications to a core tiddler, allow one to be applied, then use one of the above methods to implement one or both of the modifications so they both work together if at all possible.

• Advise the designer of the solution(s) you were installing so they can improve their package to use this alternative to core tiddler modification.