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.
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.
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.
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.
These features could create a mass of possibilities of proliferation in custom layout configurations without users needing to know js.
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:
- Present the filter results as a semantic HTML list so that it is easier to apply CSS styling
- Display debugging information about the filter, making it a convenient way to explore how a particular filter is evaluated in a particular context (I’ve been exploring filter debugging in Filter inspection for debugging by Jermolene · Pull Request #9003 · TiddlyWiki/TiddlyWiki5 · GitHub
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.
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.
I can confirm that I for one use the stand-alone version only for temporary debugging… for exactly the reasons you describe.
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>
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.
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
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.
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:
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?
Or did that already happen?!
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.
Right. Given that for many end-users (though not all) import and export are both central to getting the best usage of TW—I’d really like to see both better grained control of import and export; and more documentation on how to write importers and exporters.
This is an interesting and informative thread and has shown me many things I was unaware TW could be applied to. Certainly, at my stage of TW expertise, these are way beyond what I would tackle but knowing about them is great.
I am a bit concerned though that in reading the suggestions for ‘improvement/enhancement’ of TW, we might be putting ourselves in a position that TW becomes ‘just another browser app’ rather than the different approach it currently holds.
Right now, TW has few competitors that I am aware of. If we just become another browser app, then all other browsers become competitors and we may end up continually chasing the tail of others developments. In marketing terms, why give up the high ground we currently occupy?
I think that would be a shame.
bobj
What one person sees as “modern” or “aesthetically pleasing” could look terrible to another. CSS is going to always be the way in which you manipulate how the your UI components look. Just curious, what are you referring to when you say “require end-users to manipulate JS”? I don’t think anyone needs to alter any JavaScript to get HTML UI components with CSS to look “modern” or “aesthetically pleasing”.