[TW2036] Planning for v5.4.0

#28

Great to hear this - while these types of changes are a pain, I see it as a sign of health of the platform! Sorry for the long post here, I’ve had a lot of pent-up thoughts waiting for the weekend.

Favorite things mentioned in Jeremy’s post

  • True single tiddler mode
  • Syntax highlighting
  • Links to section mark
  • :let filter run prefix (multi-value variables)
  • Changes to defaults (Filter on Advanced Search, fluid-fixed, CamelCase)

Duplicates in filters
I think this makes sense as it’s more intuitive to new users, to alleviate the pain of the change, I wonder if a “migration wizard” could scan the wiki looking for filters that might need to be changed. Maybe even with some bulk functionality of adding the needed +[unique[]] where flagged. Also, if default does changed, is there any reason to keep the :all filter run prefix or does that get deprecated also?

Event catcher syntax
The <$eventcatcher has been a lifesaver for making more performant “clickable” tables / lists. This was something @saqimtiaz pointed out some years ago in his “Performance” post: Some thoughts on performance - Developers - Talk TW. I still go back and review that post regularly! Does the above imply that this solution would go away? Would there be something else to replace it?

Filtered Transclusion
This was mentioned by others already, but this is currently a FREQUENTLY used syntax and one of the primary ways we avoid needing <$wikify>. Other than I wish it didn’t produce links, can I learn more about proposed changes?

Keyboard driven input macro
This sounds really interesting and I’d like to learn more. I’ve tried to follow the guide setting things up but it’s surprisingly complex how it’s put together. It sounds like better primatives would be awesome! I use TONS of keyboard shortcuts but just do it in a homebrew way that’s easier for me to understand.

Advanced Search
Defaulting to filter makes sense here. A couple of other ideas that might make sense:

  1. A “fuzzy” search tab. I know this has been proposed for the main search though I worry about the performance implications, I think it’s more easily justifiable in a tab.
  2. A “query” search tab. I add this to all of my wikis and could share it, but it’s essentially just having two filter boxes, the normal one works just like filter and returns tiddlers, and then the second box is a filter expression that outputs the columns to present in a table. In mine, I also use an eventcatcher so that clicking any cell allows you to enter new values, great for quick editing.
  3. An “update” tab. Taking the previous concept one step further, some simple version of a batch editor. @Mohammad 's is very popular, I have my own simpler one, but again very handy and this is a good place to house it in my opinion.

Layout
Mentioned is an Obsidian/Notion like layout available. Layout is a huge point of customization that hasn’t been made that much easier over the years. My suggestion would be to build a somewhat “generalized” structure that can be easily customized to look like people’s favorite tool. A great foundation is the “Holy Grail Layout.” Wikipedia. Header, Footer, and a sidebar on each page. If that was the core, you could still default it to look like it does today (setting leftbar width to 0, topbar to 0, bottombar to 0. The tutorial by @Brian_Radspinner Tutorial: a basic alternative layout - Tips & Tricks - Talk TW is another tutorial I look at often and gets you most of the way.

ActionWidget Execution Modes
I’m surprised that this ActionWidget Execution Modes wasn’t mentioned - the tiddler mentions backwards capability right in it. This is an ongoing source of confusion for people as they start building things with buttons. It comes up in the forum often as the default setting makes TiddlyWiki seem broken.

Relink
I can’t help myself but again suggest that this is really missing core functionality and the fact that we rely on a plugin to do it seems very strange and concerning. Maybe @Flibbles’s plugin can be slimmed down for the core, but having it in the core would ease people’s anxiety about the future of this.

Sorry for the long post - I’m thankful for TiddlyWiki and have been using it nearly daily for the last 20 years!

#29

Is this regarding the actions and events attributes of eventcatcher that are already mentioned in the documentation as deprecated

#30

A post was split to a new topic: How Create a Query in $:/AdvancedSearch

#31

As a side note, if we need to do a major version update, then the documentation should be supplemented with as many rich examples as possible. Otherwise, we’ll be asking all sorts of questions on the forums again about the content after the update, whether it’s new or old changes. I know that the forums are very enthusiastic and helpful, but good documentation with lots of examples would probably reduce a lot of unnecessary problems. In fact, there are some solutions that could be put into the documentation, as having such explanations would allow a better understanding of what some of the new features do. Similar to TW-Scripts, but put the content in the documentation instead of a separate project. Because the content of the documentation will be translated by someone, a separate project will rarely be translated.

#32

Just to add my two cents about uglifying. I don’t know if the core should be uglified by default. The advantage of the Uglify plugin is that if one wants uglified code, all they need do is include the plugin (or run their file through the wizard if they’re not using Node.JS).

This allows users to have their cake and eat it too. They can have uglified code quite easily, or if they want easy-to-work-with code, then they don’t. If we uglify by default, then we’re forcing end-users’ hands.

6 Likes
#33

I wouldn’t be against Relink being added to the core. Its size would come down quite a bit from doing that, because a significant part of its code is about tampering with parts of core to make it do what it wants.

It also goes to major steps to be able to relink in extreme edge cases, and if we’re willing to drop that, it also slims quite a bit.

Though the strong argument against merging it is that currently it’s maintained by me, and that it gets kept up to date with new releases with no extra effort from the core team. The only price is that I get pissed off and snip at people on the forums for every major release.

4 Likes
#34

2 posts were split to a new topic: IOS Problem using TW textarea

#35

The nature of these is that they might be off, but that the spirit of them would be great any way closest they can be accomplished without breaking the dedication level to backwards/forwards compatibility.

These UI feature suggestions:

  • A default left sidebar option, to whatever degree can mirror the right one on a core level, but without filling it with content yet, until such further potential development. This would not require showing it by default, but presenting it as an option that users can fill in with their own sections in a similar way to the right sidebar.
  • Basic line numbers in the editor without a special editor
  • saving tiddlers in edit mode while it stays open, without re-navigating to the tiddler, and loosing place in the editor.
  • I noticed some deeper widgets/messages are tied between tiddler creation navigation, and the vanilla theme, making it weird to create different tiddler creation and navigation scenarios with different imagined layout configurations. (This might be related to something that was mentioned already.) . . . . From what I vaguely remember, this could be accomplished by splitting some messages into multiple steps of smaller messages. Compatibility would be accomplished by making the existing messages perform these multiple operations.
  • Perhaps related to the above scenarios, is to have custom alternate river locations built in to be able to send links to custom locations without js. Persisting behavior could otherwise be exactly the same without specifying a custom open location in a link and/or markdown.

These features could create a mass of possibilities of proliferation in custom layout configurations without users needing to know js.

1 Like
#36

Thank you for the thoughtful and useful feedback. I’ve made some edits to the OP which I have marked with the date.

Yes, the idea is to expose low level primitives that allow deep customisation of the location hash behaviour.

There would be a global setting to control the deduplication behaviour. I am also hoping to offer the ability to switch between modes on a per-filter basis, and the ability to control deduplication via a variable.

The primary work involved with this is to go through the core and ensure that there are no dependencies on the current deduplication setting.

I agree that an official plugin library is vital to the future of TiddlyWiki. However, I think we would be wise to treat improvements to the plugin library as out of scope for v5.4.0. There is a lot of work involved, and a good deal of that work is tasks that fall outside of the core development that is the focus for v5.4.0.

This comes up regularly, and I very much like that there are experiments in this area.

However, while I am sympathetic to the desire to optimise the performance per byte ratio, there is a trade-off here: it would make supporting TiddlyWiki users more complex because we would be dealing with what would amount to a series of different TiddlyWikis, each with their own selection of core tiddlers and plugins.

I like to talk about universality as one of the key goals of the core. It’s a useful way of thinking about several different aspects of the development of TiddlyWIki:

  • Universality of usefulness is an important criterion for inclusion of a feature in the core. (If a specific feature is deemed to have too narrow a use case to make it into the core, then we would generally instead add the hooks to make it possible to implement the feature in a plugin)
  • Universality of audience means that we want TiddlyWiki to be accessible to everybody in the world, regardless of language, disability, culture, but united in the desire to make sense of a complex world
  • Universality of platform is the idea that TiddlyWiki should support the widest possible range of devices, browsers, operating system etc.

I am not referring to the filtered attribute syntax like this:

<$text text={{{ [<myvar>addprefix<anothervar>] }}}/>

The problems are around using the triple brace syntax on its own:

{{{ [<myvar>addprefix<anothervar>] }}}

As things stand, that syntax produces a list of linked titles returned by the filter. Sadly, it just produces a stack of DIVs and not a semantic HTML list

My guess is that this syntax is rarely used because it is so limited. Part of the process of the development v5.4.0 is to validate those assumptions.

If we do decide to redefine this syntax, there is an opportunity to think up some useful alternative meanings. For example:

It would be fantastic if we could mobilise a team to focus on documentation improvements. We’ve had some incredibly useful contributions over the years and yet there is always more to do.

My thoughts on this are included in the associated GitHub thread. While it may be appropriate to use ES2024 in some subsidiary projects like MWS, I think we should continue to target a relatively conservative subset of JavaScript, albeit more modern than at present. I think this approach is enormously beneficial to end users, and doesn’t hit developers too hard.

We’ve had a few attempts at this over the years, but nothing that has been truly satisfactory. I am confident that implementing this feature would require at least a modest break in backwards compatibility, and so we should definitely give it consideration for v5.4.0.

There have been improvements to permalink handling that go a long towards making linking to section marks viable. However, my sense is that users actually want something more ambitious: to be able to address a section of a tiddler in such a way that it can be used anywhere a tiddler can be used. In other words, being able to transclude just the chunk of a tiddler delimited by two section marks.

I would like to explore whether we can find a viable approach. There is a possibility that we could somehow be able to optionally treat wikitext tiddlers as if they were plugins with each section being a separate shadow tiddler. More thinking is definitely needed; we need a solution that is elegant and easy to use.

We’ll change the filters in the core to work in either mode.

When we’ve experimented with disabling deduplication in the core we actually found that the broken cases were relatively easy to spot; typically, the giveaway would be duplicate items appearing in a list that shouldn’t have duplicates.

Excellent point, thank you.I will add it to the OP.

I think that might be the best approach. I will add it to the OP in the section about staying competitive.

9 Likes
#37

For what it’s worth, I use this syntax regularly, especially for testing purposes, and use the {{{ filter || template }}} syntax even more often — essentially, whenever I don’t need to define any of the other $list attributes. I would be sad to lose the current functionality, and it would also break a number of my templates.

ETA: One common scenario in which I’d use {{{ [<myvar>addprefix<anothervar>] }}} alone (i.e., without a transclusion template) is to display an inline link to the single-tiddler output of the filter if and only if it exists — thus, as a shorter alternative to <$link to={{{ [<myvar>addprefix<anothervar>] }}} /> or <$list filter="[<myvar>addprefix<anothervar>]"/>. In such cases, I wouldn’t want it to default to <ul><li><$link/></li></ul>.

In instances in which I do want filter results in an unordered list, I normally use <<list-links "[<myvar>addprefix<anothervar>]">> instead.

1 Like
#38

I can confirm that I for one use the stand-alone version only for temporary debugging… for exactly the reasons you describe.

1 Like
#39

Yes, I do that a lot too. Even though I know its practically equivalent to the following, I still favour this shortcut syntax. This further raises the question, how consistent is TiddlyWiki’s shortcut syntax, and will this incompatible update break the previous shortcut syntax? Because I’ve always preferred to use the shortcut syntax when I’ve grasped what it means.

<$list filter="[<myvar>addprefix<anothervar>]">
	<$transclude tiddler="template" />
</$list>
#40

Incompatible updates can include updates that are more friendly to newbies. For example, as mentioned here, add a hidden setting to turn off drag and drop importing in Story River. I often run into this problem when I visit many TiddlyWiki sites.

#41

I noticed this when i re-read the OP after I had posted about the plugin mechanism - so fair call on keeping it out of scope for now. Good to know that it is on the radar as a vital feature.

Given that this is a growing build up of planning over future releases - have you considered using the Projects feature of GitHub so its clear whats in this release and whats a priority for future releases ? I imagine it could also help track anyone who volunteers to work on code or documentation changes prior to the PR being raised ?

CB

1 Like
#42

A post was split to a new topic: [MWS] Questions about Bags and Recipes

#43

from user point of view, <<list-links [<myvar>addprefix<anothervar>] >> works well, it’s clear what the purpose of the filter is.
I also use the shortcut inside codeblocks for debugging eg

\function lf()[charcode[10]]
<$codeblock code={{{ [<myvar>addprefix<anothervar>] +[join<lf>] }}} />

I have always thought of it more as a tool, I never really thought this shortcut syntax was intended for use in wikitext body.

#44

Fascinating discussion. I appreciate the rigor with which Jeremy is approaching the new version. I am learning a lot as I catch up in this thread.

FWIW I do use this filtered transclusion shortcut syntax in my right sidebar tabs. I find it useful beyond simply for testing filters.

Table of Contents tiddler example:

2 Likes
#45

On a non technical note, would this be a good time to move the default icon set over to one @jeremyruston you were discussing …some time ago?

1 Like
#46

Or did that already happen?!

#47

I suggest we try to tackle refactoring the import process as part of v5.4.0, to allow for manually switching which deserializer is used and thus allowing for greater end user control over how data to be imported is interpreted.