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

#1

a discussion with a view to improving tiddlywiki

I have a useful modification to $:/core/macros/tag that allows tag pills to be provided a label rather than the tag name.

  • This is a great alternative for long system tags
  • I also have a useful modification to $:/core/macros/tag and S:/core/ui/Tiddlerlcon that allows tiddler icons to use wiki text, just not tiddler icon names.
    • using an icon field to test for the existence of the icon tiddler given and use that (default behaviour)
    • otherwise it will wikify the content of the icon field allowing conditional icons and or wikitext and Unicode to be used as the icon.

First Question

How do you handle circumstances like this? Do you;

  • Make a new tiddler containing both modifications?
    • If you do, do you have any tips and tricks?
  • Choose one modification over the other?
  • Make a new package that incorporates the function of both features.
  • Sometimes you can’t simply accept both changes as it requires further intervention to make them compatible.

I can see the possibility of allowing the import process to process the additions it has contained in it, while permitting existing changes to remain. It would be at the designer’s discretion if this will work and there is no clash.;

Second question

One way to resolve this is to consider submitting one or both changes as a tiddlywiki core change so you don’t need to install packages and even face this overwrite dilemma. This has a longer process to achieve it.

  • What do you think of me proposing these changes?
    • Improve the icon field to permit wiki-text when the icon image tiddler does not exist
    • Improve the tag pill macros/templates to allow the tiddler name to be overridden with a label.

Third question

If you have come across the issues these workaround address, how have you delt with it? either a solution or at least a work around?

#2

I was struggling with that exact thing today! I got a half-hearted solution that works well enough for my current needs, but would be interested in seeing a more robust solution if you have one.

It’s not always possible – but it commonly is – that you can refactor the underlying code, here the tag macro code, in such a way that that the difference between the original behavior and the new one is encapsulated in a separate chunk. For Tiddlywiki that chunk would almost certainly be a new tiddler, or several. So you can split $:/core/macros/tag into $:/core/macros/tag and $:/core/macros/tag/handle-name, and keep the functionality intact. But you can also create an alternate version of $:/core/macros/tag/handle-name, that allows for labels. The idea is that you distribute this with a package including your new version of .../tag and your overridden .../tag/handle-name.

Then you do the same thing, extracting $:/core/macros/tag/handle-icon, but you do it atop the already overridden $:/core/macros/tag. And again you make sure it works as expected before you create a second version of ...tag/handle-icon. Once it’s working fine, you create the override for icon handling, and you now have five tiddlers to include, but each version includes only three of them:

  • The current baseline with no changes includes .../tag as well as the original versions of ...tags/handle-name and ...tag/handle-icon
  • The updated name-handling version substitutes the new version of ...tag/handle-name
  • The updated icon-handling version substitutes the new version of ...tag/handle-icon
  • And of course the combined one substitutes both of them.

This is workable as is, but we can take it one step further by adding a configuration parameter somewhere (control panel?) that dictates each of these decisions, pointing to either of the newly-named ...tag/handle-name-default and ...tag/handle-name-with-labels, and the same for icons. Now you can happily bundle all these together and simply override the default behavior with one configuration change per topic. Moreover, you or someone else can now easily add additional functionality to these two areas just with new versions of either of these topic’s tiddlers.

Congratulations! At this point you’ve introduced hooks, a very powerful technique for allowing overrides of certain parts of behavior without re-implementing a core system.

1 Like
#3

Thanks @Scott_Sauyet That is a good design approach, and thanks for the reply. I suppose I am also wondering, what is best to do if you were not the designer and suddenly bump info this issue?

  • I am speculating there may be simple ways to address this?
    • For example if on review we knew the changes from one, could be merged with the other, could we have a button to apply only the changes from the current tiddler to the “shared tiddler”, retaining the prior change?
  • Or perhaps like your approach, a de facto approach we can share to help.

Can we help design solutions so they can be better managed should one converge on another?

#4

It would be nice to see an example. I do not really get what you want to achieve.

At the moment there are 28 physical system tags: [all[shadows]sort[title]prefix[$:/tags/]].

If a system-tag does exist as a tiddler, it’s possible to add fields like caption or description.

It’s important that those captions or descriptions have to be translatable, which makes the whole process a lot more complex.

Did you take different languages into account?

#5

I am looking for my latest package with this modification, but to put it simply it simply allows a label to replace the name on the tag pill which is normally the tag.

So you can use the tag pill in a wider range of circumstances and works well with my reimagine tags package of tools on the tag pill.

Eg use the tag macro for

  • $:/tags/ViewTemplate with the label “view Template” shorter an more meaningful
  • For the current tiddler with the label “tagging” or “children”, no need to display the current tiddler, you know it already, explain what items tagged are in the label.

Here we are not for publishing yet labels-on-tag-pills.json (3.8 KB)

I like to use it to put tag pills in the tiddler subtitle

#6

I will try modify core to add a new “slot” or hook, so I can modify it in the next release. And I will use an workaround for now.

#7

In this case I own both packages that clash. Thus I have decided to retain the seperate packages but creat a third combined one.

  • but if we could capture changes found in the import preview, not import the modified tiddler and then apply the changes to the shared tiddler, it would make it easy to implement a work around in some cases.
1 Like
#8

OK. But in my opinion that does not solve a problem, IMO it hides it. Which makes the situation more complex and not less.

There are several reasons why $:/tags/ViewTemplate is named that way

  1. It’s a system tiddler.
    System tiddlers are hidden from user facing lists by default – That’s a core convention
  2. The core UI consists of many system tiddlers.
    So the core UI uses prefixes to determine what a system tiddler is used for eg:
    $:/config/, or $:/language/ and $:/tags/, which indicates it’s used as a tag.
  3. So if a tiddler is tagged: $:/tags/ViewTemplate it may be a bit alien for the user, but it makes it absolutely clear that something special is going on.
  4. A label: “view Template” looks like a standard user created tag.

Since many users usually just copy core functionality they will start tagging tiddlers with view Template and expect something special happens. … If they even understand that it’s a special tag.

So to make it clear, that it is “special” it will need a marker. – So guess, what that marker should look like?

As I wrote. IMO it does not solve a problem, it hides it and increases complexity.

IMO If we change system tags it has to be obvious for the user that it’s a system tag with a “nicer” label.

Just to make it clear. English prose text labels are also alien for German speaking users. So for “readable” labels we need to make sure, that they are translatable.

#9

Please dont take that example too seriously, it was just an example off the top of my head to explain what it allows, not what you would necessarily do.

  • By the way when you click on the tag pill you see the real name
  • With my reimagine tags you can copy the real tag, remove the tag from the current tiddler and more, so this is really not an issue.
  • perhaps if you are publishing for a global audience, and edition etc… but this solution does nothing but make it possible to provide a label in your own language, for you.

For example try this with the above installed;

<$list filter="[tag[TableOfContents]]">
   <$link/> <<tag label:" ">><br>
</$list>
  • Contains a space

you get;

Snag_30b68d6d
Snag_30b68d6d1213Ă—732 78 KB

  • With my reimagin tags

Or a tiddler tagged SystemTag: $:/tags/ViewTemplate/Subtitle containing.

<<tag label:"tagging">>

Snag_30c1dd0e
Snag_30c1dd0e1356Ă—663 62.1 KB

  • Without my reimagine tags

Finaly if your site is for not tiddlywiki literate people, system tiddlers may scare them, but they do not need to know how they work.

  • By default this is only when using the tag macro with a label not in the tag bar or edit tags.
#10

As far as I can see, this exact functionality can already be solved without any name-clashing of core tiddlers.

In the OP you asked, how we deal with “clashing” tiddlers. IMO this example cannot be used here. It does not clash

Implement it as a 3rd party plugin and we are good to go. Every user can decide if they want that function.

I personally would prefer this info in the footer. In a TagglyTagging like plugin

#11

The only reason I gave an example was because you asked;

I felt the prior conversation was sufficient for the subject, you import two tiddlers that each modify the same core tiddler. What do you do from there?

In the example of clashing mods I just happen to combine them into one;

labeled-tag-pills.json (5.0 KB)

But this changes nothing about the original topic.

To deal with a clash we need a tool in tiddlywiki to assist, ideally not something that must be added to the package.

#12

OK. Then I have to say, that at some point you have to decide if you do want to overwrite core tiddlers from a plugin or bundle of whatever.

If possible I try to overwrite the least amount needed to implement the functionality.

For my own plugins I do use this info in the readme. See: Click Effect

''Important'': This plugin modifies several core modules

<$list filter="[[$:/plugins/wikilabs/click-effect]plugintiddlers[]prefix[$:/core/]]"
  emptyMessage="-- none --"
>
    <$link to=<<currentTiddler>>>
      <<currentTiddler>><br>
    </$link>
</$list>

If the plugin is successful, you can try create PRs to the core that make “hacking” easier or less error prone. Be prepared, that this can be a lengthy process.

#13

You cannot use them together. As simple as that. – Sometimes you cannot have it all

#14

Perhaps you cant, but you can work around it, this is about the process, the how to and how can we make it easier. Review each change and manually apply them is one approach.

  • My feeling at the moment is we may be able to copy the changes from the import difference view and apply it to the existing one.
    • The exception being when they are intermingled.
#15

I think: As soon as “manually” is part of the process it will fail because there will always be a delay or the maintainer is completely gone.

I think at the moment there is a good time to get “hackability” into the core. Most core UI functions still use \define and slow text substitutions. So improvements can happen if \procedures, \functions or imo even better parametrised transclusions are used and directly contributed upstream.

→ The main barrier I see is backwards compatibility.

Since v5.3.x all the “higher level abstractions” are implemented as transclusions. So \define, \procedure, \function end up being executed as parametrised transclusion widgets.

So understanding transclusions, the slot-widget and the fill-widget in detail will probably open completely new possibilities to create dynamic and hackable UIs.

But a lot more experimenting will be needed to see and explore the full potential.

From my point of view - a new UI from scratch, with a new focus is the way to go.

#16

That may be true again, but I think you miss the point. How do you do it, what is the minimum that needs to be done, how can we do it better? What tools are available.

Once we work this out we can automate.

  • I can’t agree more, and I am quickly becoming well informed on these.

One approach I have looked at is having a macro/procedure by the same name as a core macro that with an additional parameter behaves differently and without, uses the core macro.

  • In the case of the tag macro it uses both macros and a transclusion so it is not as open to this kind of override.
  • However one of the subjects I raised, is the possibility of passing the result from the parameter widgets $params variable simply being passed to a macro or widget it calls.
#17

There’s always a balance. We can make it easier and easier to override many pieces of the core. But the more hooks we provide, the more complex the implementation is and the harder it is to thoroughly understand it.

Tiddlywiki has always aimed toward the more hackable side. Just look at the number of settings in the control panel tabs/subtabs to confirm this. Beyond that, everything outside boot is overridable, it seems.

But this can always be extended, offering additional abstractions, additional overridable hooks. The Fundamental Theorem of Software Engineering states that

We can solve any problem by introducing an extra level of indirection.

But at some point the additional complexity makes this more difficult. For the case in question, in @TW_Tone’s position, I would want to try to make my modifications to the base clean enough to be taken up in the core, so that eventually I can maintain only my extensions… if they themselves do not make it into the core.

#18

I was falling asleep as I added my first answer, so went to bed. I didn’t want to forget to answer the second question in the OP.

I like the idea of allowing wiki-text in place of (or alongside) the icon image. But if you’re saying that we check for the existence of a tiddler with the title found in the icon field, and if it’s not found, then treat the text of icon as wiki-text, then I strongly disagree with the implementation. Multipurpose fields are an anti-pattern, and can easily lead to problems down the road.

Instead, I would suggest that we have some sort of cascade-like mechanism that uses a different field or a separate template or something else, anything that doesn’t treat icon as meaning one thing based on one type of value and something entirely different for a different type.

I’m working on a wiki right now, in fact, that uses the icon field – as an icon – in an entirely different way. I don’t think it would break anything if you had wikitext in the field instead of the title of an image tiddler. But I wouldn’t want to count on that.

I would love to see extensions in two different directions. One is to use the tag pill UI to work with a label and an arbitrary filter that leads to a list of tiddler titles It would also be useful if the default <$link /> could be replaced by another template, like <$link>{{!!caption}}</$link>, or something more complex. I don’t know if there’s anything like that available.

The other is to simply change the label on the existing tag pill. @Mark_S has demonstrated that, and I’d love to see this make it into the core.

#19

Thanks again for yours ideas @Scott_Sauyet

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.
  • so this is an example of a package that extends functionality and increases hackability of the core.

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.

  • usualy introduction of a new hook needs very few additional bytes, is backward compatible, often more efficient and reduces the clashes that this topic is taking about.
  • but yes we need to be circumspect.
#20

Returning to the topic

With all our attempts to avoid changing core tiddlers sometimes we or a solution we install does. Sometimes we install two solutions that want to modify the same core tiddler. Assume here, with neither of these solutions are you the author.

What would you do to accommodate both changes in your specific wiki.

  • have you encountered this? and what tips and tricks do you employ.
  • do you document it?