Confusing discussion about backwards compatibility

#21

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 (besides state, 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.

#22

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.

#23

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
#24

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
#25

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?

#26

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
#27

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.

#28

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:

  1. 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
  2. if 2 line break, means they are in 2 different blocks.

Anyway, could we start a new thread to discuss this?

#29

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

#30

@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”

#31

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.

#32

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 :slight_smile: all thanks to the prioritization of backwards compatibility.

4 Likes
#33

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

#34

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… :smiley:

3 Likes