[TW2036] Planning for v5.4.0

[twMat]

The following would “set the stage” for future improvements. Do they qualify?

• Split up the huge vanilla stylesheet
• Enable listing of all controlpanel settings

[TiddlyTitch]

@twMat

Split up the huge vanilla stylesheet

Split up, modularize, document better.

Any of those.
CSS is massive in TW (massive size and massive importance).

I want to say, also, much/most CSS in TW is fairly logical in it’s nesting.
That is because the basic HTML of TW is as near perfect as is possible.

A footnote, TT

[nemo]

@pmario

Due to lifetime of iOS mobile devices there is a high chance, that we have enough devices out there which do not use the latest Safari browser.

So my oncall phone is an iPhone 6s. These were first released over 9 and a half years ago, and discontinued 3 years later. As a physical device it’s beyond the 5 year window.

It’s OS is iOS15, which is still supported by Apple, with the most recent release being March this year - approx 6 weeks ago.

Looking for a ecmascript version detection site, it seems it’s a mess since browsers may support a subset of features. But anyway, I ended up checking with this one: https://stackoverflow.com/questions/47374678/how-to-detect-ecmascript-version (which has three tests within the answers)

• iPhone 6s running iOS 15.8.4:
  1. ES6 supported / ES100 not supported
  2. Edition 13 / 2022
  3. Version 13 / 2022

By comparison, my iPhone 14pro running the very latest iOS18, desktop Firefox (135) and desktop Chromium (136) all get the same answer on the first two, and “Version 14 / 2023” on the third.

Granted this is a pretty simplistic test, of a single device (and apparently the 6s is a bit unusual in it’s support longevity). Nonetheless, as of right now this 9.5 year old iOS mobile appears to be 2022 compatible… I think that puts a reasonable case that supporting a 2020 era dialect of JS should be fine?

If there are concerns about any given new JS feature, I’m sure a simple test page can be made that I and others would be happy to check and report back on with a variety of devices.

[wattahay]

Table Syntax Idea That Does Not Brake Backwards Compatibility

This improves table readability, and editability.

| first row, first column |
=|second column|
=|third column|
=|fourth column|
| second row, first column| second column|
=|third column|
=|fourth coumn|
| third row, first column|
=| joined column|<|
=|third (fourth) column|

• Adding a symbol like ‘=’ to each column makes for a flexible syntax that can handle current use cases.
• Future auto-editors could also auto-fill the symbol according to the first row’s columns.
• Each new row stands out visually almost like it is indented.
• adding a single symbol does not increase typing very much.
• Note how you can still combine old and new syntax.
• It’s possible that this would have ramifications for templates and lists

Conceivably it would be reversed, so that the symbol was at the beginning of each row. However this would not be backwards compatible.

The only potential problem I see with this is if the parser would need an indicator at the end of the lines as well . . . as a sign to continue.

ie:

| first row, first column |=
=|second column|=
=|third column|=
=|fourth column|fifth column|
|second row, first column|~|=
=|third column|=
=|>|joined forth/fifth column|

Yet another possibility is to leave the ending open altogether to save typing:

| first row, first column
=|second column|third column
=|fourth column
=|fifth column|
|second row, first column
=|second column|third column
=|fourth column
=|fifth column|
|third row, first column|second column|third column|fourth column|fifth column|

[jeremyruston]

Thanks again to everyone for the feedback.

@etardiff

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

Thanks @etardiff that is a helpful scenario, and I think rules out making changes to the top level tripe brace syntax for the moment. I have amended the OP.

@Christian_Byron

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 ?

Thanks @Christian_Byron that’s a good point. As mentioned in the main 2036 thread, I would like to move the project to a sustainable and formal organisation. I think the key is to get more people involved by forming teams with responsibility for particular areas (eg @Arlen22 leading the MWS development). I would like to start having regular calls for core development, and I can imagine using the GitHub Projects feature as both the agenda and minutes of the planning parts of the meetings.

@Ste_W

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?

I think that makes sense. It would be useful for v5.4.0 to be a little visually distinct from earlier versions. I’ve updated the OP with a new section under the heading “Visual Refresh”.

@saqimtiaz

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.

Thanks @saqimtiaz I’ve updated the OP.

@dongrentianyu

TiddlyWiki should provide a basic, better looking style

An important reason that TiddlyWiki does not restyle system controls is because it is very hard to do so without degrading the experience for users of assistive technology (screen readers etc).

@twMat

The following would “set the stage” for future improvements. Do they qualify?

• Split up the huge vanilla stylesheet
• Enable listing of all controlpanel settings

Hi @twMat. I think splitting up the vanilla stylesheet could be done without affecting backwards compatibility. Picking up the control panel modifications is a good idea, and I’ve added it to the OP.

@wattahay

Table Syntax Idea That Does Not Brake Backwards Compatibility

Thanks @wattahay that’s a good suggestion. As you note, it shouldn’t present backwards compatibility issues, and so we can address it after v5.4.0. I’d be grateful if you could make a GitHub ticket so that the idea is not lost.

[ShadowTiddlers]

@yan

Linux users (like yours truly) can solve their own problems

This Comment Broke Me, I laughed so hard being a linux user myself idk why but I just found this Lil note funny like “yeah, for linux users we’ll just duct-tape it together ourselves”. Also the for the EoL cycle info,

[ShadowTiddlers]

I am sad to see IE support die (primarily due to HTA Hacking TW5) but i understand entirely why this needed to happen, HTA is already a bit unstable when it comes to plugins. I genuinely look forward to the possibilities that tw5.4.0 will bring

[jeremyruston]

@Christian_Byron

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 ?

@saqimtiaz has kindly worked with me to create an initial project plan on GitHub:

Planning for v5.4.0 • TiddlyWiki

There is also a GitHub ticket for discussing the project plan:

Planning v5.4.0

Project management is far from my comfort zone, so I would welcome help on this side of things.

[twMat]

@jeremyruston

[…] table stakes for note taking software

These days, because of social platforms, I’d say @ and # are universal even in note taking software.

[TW_Tones]

@Flibbles

I don’t know if the core should be uglified by default.

A key advantage if tiddlywiki is open and readable source. I have long stood by the fact if you were stuck on a desert islan with a copy of empty.html or better yet tiddlywiki.com you would have sufficent information to develop almost anything by reverse engeneering the source.

• I see value in documentation in relation to breaking backward compatibility so that it is always possible for someone determined to do so to update there wiki and or plugins to work (on a desert island)
• We often see here people asking how to do something, that if you look around tiddlywiki you ofen find (a form of it at least) already available in the core, thus can find the nessasary code patterns needed.
• Something I know is missing in the empty.html is all the as yet unused system tags, thus I made a utility for this, however if you delve into the “readable open source” you can find them, and what they do.

[Mohammad]

According to the to-do list, Feather/Lucid is set to replace the current icon set. Would it be possible to allow users to install or switch between different icon sets seamlessly? Similar to palettes, an icon set could be selected and applied as desired. I appreciate the current thick icon set, and would like the option to retain it or switch to the Lucid icon set.

[TW_Tones]

@wattahay

saving tiddlers in edit mode while it stays open, without re-navigating to the tiddler, and loosing place in the editor.

Perhaps the popular Extra editor toolbar buttons, discard and close, confirm and close and Confirm and keep open should be added to the core (even before 5.4) and make them optional see $:/plugins/telmiger/EditButtons

• Idealy we could find a way to restore the cursor in the last case.

@jeremyruston

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.

Can we support different outputs through the template with Filtered Transclusions? eg {{{ [tag[mechanism]]||TemplateTitle }}}

• I played with this for sometime in the past because I wanted to make a set of plan english template names that would output the list of tiddler titles in different ways.

[TW_Tones]

@TiddlyTitch

I want to say, also, much/most CSS in TW is fairly logical in it’s nesting.
That is because the basic HTML of TW is as near perfect as is possible.

But there are a number of features above HTML/CSS that influences the output, such as the ability to reorder stylesheets, the ability to reference external CSS and the way tiddlywiki manages its components with CSS like colours and themes.

As a result I would love to see a systematic documentation of this to assist both script kiddies like me and experts alike to see how TiddlyWiki plays along with CSS. This meta layer can also assist sophisticated CSS users to build and test CSS and layouts.

@jeremyruston

Allowing comments within filters

I already found some methods to do this using functions that just pass through all titles and the parameter can include notes. Wether this is enhanced with a different syntax it could still use the same method and provide an alternative syntax to also use funtions.

• Ask if examples required.

@jeremyruston

minor practical impact from making the default behaviour be to allow duplicates within filter expressions.

For many real world functions removing duplicates is a good default, for example combining sets of tiddlers using a set of tags, no additional thinking is needed to remove the duplicates if a tittle is tagged by more than one tiddler.

• I personaly would not like this happening becase then tiddlywiki will move away from an intuitive no duplicates to a non intuitive, except for mathematics, generation of duplicates.

Possible from a naieve perspective what about instead;

• An alternative widget parmaters all.filter="filters that retains duplicates" even if this just then passes a reformed filter to the filters= parmeter.
• The aformentioned idea of a variable that switches on a a duplicate handling mode in widgets.
• A header in a filter filter="[duplicates[on]]" perhaps it can join [all[]] and all[system]]

In Closing

We should where possible find solutions that do not damage backwards compatibility and I belive we have not yet explored the suit of possibilities to solve many problems without breaking backwards compatibility, especialy when there are ways to introduce alternate mechanisiums, altered widgets (eg new parmeters) or additional syntax.

• Providing local overrides and global switches can also allow a user designer to activate a new behaviour if desired, without altering the default behaviours.

Not withstanding the above there may very well be things that need to be broken, but every effort should be made to avoid doing so.

[Edited] I have not used dupl;icates often enough to be sure but I expect outside of filters there are a limited set of widgets that someone would use when processing duplicates for maths purposes. What if we had a mathfilter? or specific syntax for filters that retain duplicates.

[Scott_Sauyet]

@TW_Tones

I have long stood by the fact if you were stuck on a desert islan with a copy of empty.html or better yet tiddlywiki.com you would have sufficent information to develop almost anything by reverse engeneering the source.

You know, Tones, you have an unusual choice in what you’re taking to a deserted island.

Me, I’m asking for a huge cache of food and fresh water. Oh yeah, and a boat.

[wattahay]

@TW_Tones

Idealy we could find a way to restore the cursor in the last case.

Is there a standard, non-Vanilla theme way to have an editor open on a separate basis?

(This is just honestly a thought I had, and so if it’s not “inspired” then it’s not inspired thanks.)

The depth of this issue is that the editing is actually literally a separate temporary Tiddler, and that is not able to change from what I understand.

A side question I have had for a little while is: How easy is it to facilitate a slightly different theme, where the same edit-mode for tiddlers can basically get opened in a different river, or in the sidebar? In this case, there would be no re-opening at all - just 2 separately opened modes.

The two seem to be unnecessarily entangled too intrinsically anyway.

It’s been a while since I have been looking at it, but I think edit mode is a template. In summary: How inconvenient/incompatible is it to program the ability for users to implement a separate edit mode on a separate basis altogether? Plus it could open up more design possibilities than just this aspect of re-opening.

[TW_Tones]

Smart ideas @wattahay but the community is ahead of you on this one.

You may find this better as a thread of its own. There are multiple opportunities to do what you want with the current versions, from multiple story rivers, edit in the sidebar, to open for edit in a new window, with or without closing the tiddler in the view template allowing a preview of the edit, this is why some favor wysiwyg, as its both at once.

• Although such additions to future versions may be good they need not break backwards compatibility which is what 5.4.x is about.

[wattahay]

Narenj 0.5.1

You know what, I had searched for almost exactly this before, but couldn’t find anything like it.

However I wonder: with his/her amount of knowledge, would* it not be so easy to use the same template as the regular editor?

edit: By, “would it not” I mean literally perhaps “should it not” be that easy. If it were that easy, then the plugin would probably not have to re-do it for instance. It’s more of a thought about the core for the sake of enabling the community in this regard.

[TiddlyTitch]

@TW_Tones

Something I know is missing in the empty.html is all the as yet unused system tags

You mean an instance of any use for each of the UNused System tags does not exist in Empty?
Yes?

Taggery in TW is a triple: brilliant, fundamental, and ultra-flexy.

TAG MANAGER

My suggest here is to Enhance The Tag Manager to give it easier powers to … Create Tag Tiddlers for any unused System Tag. And give more options on tag manipulation in general. Should not add much code?

IMO the Tag Manager is underused and with a bit of love could live up to it’s name and become a major way to understand and improve one’s own wikis.

TT

[TW_Tones]

My personal solution to missing system tags is a small package that list all system tags known to tiddlywiki, that I have collected in an additional sidebar > more tab. However I also use my Reimagin tags package that adds a lot of additional features to the tag pill dropdown.

The Question is what should move into the core, however none of these are breaking backwards compatibility.