To a new user, all features are new. It’s not having the ones that they would expect with any other application that is the problem.
I’m a bit different, I always like to use the latest version of TiddlyWiki. Sometimes I even go to the pre-release versions and see what new features I need in them. Even those preview versions that haven’t been incorporated into the core yet. Using the latest version of TiddlyWiki avoids a lot of unnecessary problems and gives access to a lot of new features. And I highly recommend upgrading the wiki as TiddlyWiki is upgraded, which can be seen as a test, both of TiddlyWiki and of yourself wiki. On the other hand, when upgrading TiddlyWiki across many versions, it can be difficult to solve problems that arise, because it’s not clear if the problem is brought by the new version or by one of the previous version updates.
And, the plugin will mostly use the latest syntax of TiddlyWiki. I can’t get away from shortcut syntax expressions anymore, both in the little things I’ve written myself and in my plugins, which heavily include shortcut syntax expressions. I’m sure other plugins will be the same. Of course we can stay in one version forever, and plugins stay in that version forever. But plugins, or TiddlyWiki, are not everything. If there’s a problem you want to solve, then maybe the plugin author has already solved it, and an update to the plugin will make it happen, so why not?
TiddlyWiki’s syntax is indeed a bit complex and confusing. This is probably because define and procedure share an internal set of variable definitions. I.e. the usage of $x$ can also be used in procedure, which may be worth discussing in more depth. At this point, my view is that it’s good to find what you’re used to using, as long as it’s not deprecated and not recommended.
1 Like
Agree break the backward compability, we can even start a working group to help migrate outdated popular plugins, like GitHub - flibbles/tw5-graph: Dynamic and customizable graphing library for Tiddlywiki5 do for GitHub - felixhayashi/TW5-TiddlyMap: Map drawing and topic visualization for your wiki .
It was boring to understand other programmers. But with AI, it is much easier. I’m not the creator of GitHub - tiddly-gittly/TiddlyWiki-CPL: TiddlyWiki5 Plugin Library for TiddlyWiki Global Communities, but I already update it with AI for several new features without understanding most of its tedious long code. I thought it would be unrealiable, but I find we could ask it to write test, so there will be no regression.
Another brighter future is that, software / plugins could be dynamic generated when needed. So if some of plugins are outdated, very possible that a people will stand and generate a new one with similar feature for the new TiddlyWiki platfrom version. Old plugins’s value will fade out even more faster.
1 Like
My $0.02 about backwards compatibility - I think in TiddlyWiki it’s a spectrum:
- I’d expect that “plain” tiddlers will continue to work - there’s no reason why they shouldn’t.
- I’d expect that “common” uses of filters, procedures, conditional shorthand, and macros will continue to work. Most uses of
$list,$let, the custom attribute syntax for variable / filtered inclusion, etc. - I’d expect that changes to shadow tiddlers / core enter “the danger zone”. Modifying the fields of a shadow tiddler, or changing its
text, may break in the future. This applies to anything that’s$:/prefixed (besidesstate,temp, and my own system prefixes).
I vote for breaking backwards compatibility with old versions if it allows for 5.4.0 (and future versions) to reach greater heights and more users.
One use case for breaking backwards compatibility would be to change the handling of line feeds.
It’s unintuitive to use 2 line feeds to achieve line separation, and then only display a paragraph of separation. So the only way to get single-line separation is to use a bullet point or some other similar feature.
That says all I was gonna say; better than me.
FWIW, side note, as a longer term user of TW I consider it’s longevity in part due to longer-term users staying around because they have never had to re-do much as it evolved.
1 Like
I did create the Space-Space-NewLine plugin, which allows us to create a CommonMark Hard Linebreak
It would be easy to include it into TW.
Currently there is a simple workaround without the need for bullet points. Use <br> if you need a hard-linebreak
1 Like
Right. I agree on that. I found it confusing at first—and unlike any other software.
That said, I wouldn’t give it up now if older wikis started breaking on update?
I would hate to change this.
I’ve used Markdown a bit more than I have TW’s wikitext (although the crossing point may be fast-approaching.) Markdown—in many of its variants, including the original—does the same thing, a mechanism inspired by plain text email, USENET, and other earlier communication channels. These were often delivered over systems that limited lines to some small length, such as 80 characters.
I generally format my documents that same way. Markdown was written to be familiar to users of such systems and to be readable in source form. I still really like that ideal, although working in TW has dampened that enthusiasm a bit.
But I simply find the following much less readable:
"When in the Course of human events, it becomes necessary for one people to dissolve the political bands which have connected them with another, and to assume among the powers of the earth, the separate and equal station to which the Laws of Nature and of Nature's God entitle them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation.
"We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness...."
than I do this:
"When in the Course of human events, it becomes necessary for one people to
dissolve the political bands which have connected them with another, and to
assume among the powers of the earth, the separate and equal station to which
the Laws of Nature and of Nature's God entitle them, a decent respect to the
opinions of mankind requires that they should declare the causes which impel
them to the separation.
"We hold these truths to be self-evident, that all men are created equal, that
they are endowed by their Creator with certain unalienable Rights, that among
these are Life, Liberty and the pursuit of Happiness...."
But I still want this to wrap when displayed. To combine the proper wrapping with the more readable text, I need either to signal the end of lines in some way, such as <br/> tags or @pmario’s Space-Space-Newline plugin, or to invoke some CSS to handle this, such as
<div style="white-space: pre-wrap;"> ... </div>
But that latter would then not introduce <p> elements I would like to target for styling.
I’m happier with the status quo on this.
2 Likes
I think this is the right idea. But we need to emphasize “equally” here.
We cannot lose the focus on backward compatibility, as we bring new user experience to the forefront.
I think this might be best achieved by example, though. Could we have more frequent deprecations of things that we would like to replace, but when we do so, we make sure the core and tiddlywiki.com do not use the deprecated features at all? So if we think that procedures and functions are improvements over macros, then, while we still can run macros, we have zero examples in the main code of how to use them, only documentation clearly marked “Deprecated”. I don’t know the core well enough to know if this is feasible, but that would take away one strand of the “too many different ways to do the same thing” that beguiles beginners.
Yes, I think it would be better to render a small line separation when 1 line break, and a larger line-height when 2 line break. When we will have WYSIWYG editor, it could be working like notion:
- if 1 line break, means lines are in same “block”, you can drag them together. And there can be a small line-height, just like when you “ctrl + Enter” to create an in-block line break
- if 2 line break, means they are in 2 different blocks.
Anyway, could we start a new thread to discuss this?
I would generally like to see a tighter Markdown integration and maybe even a preference towards Markdown for newly-created wikis. One hurdle that new users have to clear is to learn yet another formatting syntax, whereas Markdown is used in many other tools (which they might looking to replace with TW).
@Yaisog – There is a survey going on at the moment. At the section “Future-facing perspective on TiddlyWiki”. There is a “What could we do better?” question.
IMO that would be the right place to mention integration of “Markdown as a first class citizen”
That’s correct. This discussion doesn’t change our plans for v5.4.0.
The title I chose for this thread might have come across as a little apocalyptic. I am not suggesting that we abandon backwards compatibility, just that we reexamine the balance between the needs of new users and backwards compatibility for existing users. The ideas in the OP aren’t specific proposals so much as areas we might explore.
The reason for mentioning v5.4.0 was to question our current policy of deferring changes until the next major release if they impact backwards compatibility. The consequence of strictly following this policy is that we have useful new features that sit on the shelf for months or years. I am not sure that that is in anyone’s interests: users lose out on new features, contributors get frustrated, and there’s ultimately more work for the core development team to coordinate all these changes at once.
as others have said - it is very good for the new user experience to be able to grab any old TW5 plugin off this internet (based on forum recommendations or seeing it in another wiki) and it “just working”, no matter how old! this is a massively useful feature and was a huge selling point for me getting started with TW.
it greatly reduces the need for plugin maintenance, so there are overall a much larger number of working, useful plugins available for a new user to drag and drop into their wiki without frustration 
all thanks to the prioritization of backwards compatibility.
4 Likes
Kinda understood. But I’m now not so clear how that differs from simple “backwards compatibility kept”.
Just a query. I do understand, I think, the puzzle you wanna solve. It is not the standard debate on ‘backwards’. It is richer. But maybe not so clear.
TBH I’m not sure at what point concern with ‘backwards’ becomes incompatible with wanted/needed ‘innovation’. In other words I’m getting confused between a jump up a sub-version or whether this is a bigger version leap?
I hope my conceptual worry is clear enough!
TT
Saw this on a video about JQuery’s latest release and thought it worth sharing here…
There might be some lessons to learn from the release of jQuery 4 as there is lots of depreciated functionlity being removed and a large user base to contend with… 
3 Likes
Recently I’m trying to maintain a python library to support type hints. Because it requires python newer than 3.7, I tried to make type linting supported in older Python versions and found it very tricky:
-
X | Ysyntax is not supported in 3.7, so I have to useUnion[X,Y]andOptional[X]instead -
list[T],tuple[T]syntax is not supported, so I have to useList[T]andTuple[X], which requires adding:
from typing import List, Tuple
-
typing.Selfis not supported in python lower than 3.11
It means that I have to rewrite some of the type hints generated by basedpyright since it uses X | Y. so I mentioned them in the related issue. The owner of the repository answered that it may be better to assume python 3.12+, else it would be a maintainance headache for not many benefits.
IMO another need for breaking backward compatibility is that some new features may provide more beneficial features that adds new features or methods that makes code simpler to write and maintain (like the ?? operator in javascript and nesting and :where in CSS code). I think currently the best approach to implement a new feature may be to avoid hacky implementations and detect whether user’s browser supports a new feature and use it if possible, fallback to previous behavior if unsupported, which may encourage some users to update their browsers to benefit from new features.
So in other words. We should replace a working syntax, with a feature check and new syntax and a fallback to the old syntax if the check fails. – That’s more complex and more error prone.
IMO The solution is: Only use the syntax that works for our target.
Is it TiddlyWiki related?