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

#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?
#21

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!)

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!

#22

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.

#23

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.
  • 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.