[TW2036] Planning for v5.4.0

[pmario]

There is a proposal at GH

[Proposal] Every List-like wikitext rules shuold be 1 module. That makes it easy to disable them selectively

Since it would be a backwards incompatibility as Saq Imtiaz posted at GH it should be considered for v5.4.0

Crossposted from GitHub

Every List-like wikitext rules shuold be 1 module. That makes it easy to disable them selectively

From GG:

3 - Is a godsend where you to need switch off pragma because of use case. Why? Example: probably the worst pragma to switch-off is the Block Parse Rule for “list” because it disables ALL forms of list construct (*#:;). Example use case: Wiki concerned with posting to social networks where “#” is used all the time you need to switch of processing of “#”. …

Proposal

The /parser/list.js module should be splitted into 4:

• list-bullet.js
• list-hash.js
• list-definition.js
• list-blockquote.js

This will allow users to disable them 1 by 1 in the Control Panel. … It will probably duplicate some code. … BUT I think it would be worth the convenience. At the moment diabling the “list” rule disables 4 different elements, where 2 of them are really important “>” and “*”

[TW_Tones]

Just for clarity is it not sufficent to use ControlPanel > Advanced > Parsing to alter the state of each seperate parsing rule?

From memory there is also pragma that allows to to selectivly enable/disable rules as well so I dont think there is much reason to introduce such a compatibility break.

[pmario]

It would of they where separated. All of them are list.

[TW_Tones]

Jeremy,

In a related discussion here Using links[] in current tiddler we discovered the value of handling | delimited pairs initialy to parse out pretty|title from [[pretty|title]]and |tblecol|tablecol| so I wonder if a more general solution can be found for other.

• Handling where | is also found inside shortcut transclusions say to extract a template name etc… could also benifit.

Note:
The features we are discussing here are in someways tiddlywiki script meta issues, ie pertaining to manipulating wikitext as found, making solutions that directly interogate wiki text or text field contents (Before render) rather than simply TiddlyWiki Script and filter operators.

• By providing methods or defacto standards to support these tiddlywiki from a meta perspective is like turbocharged hackability because a designer can directly interogate TiddlyWikimarkup and script directly.
• It would be great if for example designers had access to the parsing logic already in TiddlyWiki for rendering wiki text.
  • Eg: the same rules that identify wikitext symbols.

[TW_Tones]

For 5.4.0?

I dont know if it would be a break but could we have a less complex version of the keyboard driven macro or some reusable code to make such methods easier to use?

Similarly a builder for any facility that requires multi-tiddlers to implement such as shortcuts, view and editor toolbar buttons etc… these demand too much cognative load for many uses to benefit from them.

[dongrentianyu]

In version 5.4.0 we can complete the image conversion for TiddlyWiki. It was discussed before, but maybe it can be finalised for 5.4.0. Which may also require AI for creation. Here are some links to related discussions.

Redrawing Motovun Jack

In the thread on TiddlyWiki’s 20th anniversary, I mentioned the idea of redrawing Motovun Jack: We could adopt a new or updated logo. I’ve often wanted to ask someone with actual artistic talent to make a better monochrome tracing of the original picture of Motovun Jack than my rough and ready version There’s been a good response to that idea, with @JanJo and @telmiger already making contributions. I’d like to take a bit longer to explain what the problem is. At the bottom of this post, t…

Discussion about AI created banner

Right. It was. In a way. On the other hand over use of AI images doesn’t help us. I think the poster was genuine but too naive. That is maybe the problem. AI easily creates engaging irrelevant images. Overall I, personally, am very sceptical of too easy AI image solutions. This is a side note. TT

Updated, my thought is that maybe we could use brand new animal images, or any other images for that matter. Because the cat itself has nothing to do with the connotations expressed by TiddlyWiki. Of course continuing to use the cat is ok. It’s just that I was a bit confused before, is the cat used to catch fish, to show that we are catching the idea.

Again, update, I think the cheetah is a good option if a new animal icon is used, as there are times when I see the kitten as a cheetah.

[twMat]

@jeremyruston

We would welcome , specific features to be included …break must be minor … not affect users in the field

Is now an opportunity to minify the core by splitting out some parts and make them into plugins preinstalled with the standard distro?

I can think of a few “semi bells and whistles” but a prime example would be the drawing tool. If TW had not already had one, and it was proposed as a feature today, I’d guess it would be added as a plugin (right?)

Some features are of a nature that they help you accomplish or create something at a specific occasion but, after that, they’re no longer needed. If such features have a significiant enough footprint, maybe a guiding idea for the core is to feature them as plugins?

An appealing aspect with plugins (perhaps especially, concrete items like “the drawing tool”) is that it invites for experimenting with - and developing - alternatives. Speaketh a plugin maker; It is psychologically easier to create alternative plugins than it is to create things that mess with the core and overwrite stuff. It is also practically easier to investigate something that is properly split out, e.g to see how it interfaces with the core.

Thoughts?

[TiddlyTitch]

@twMat

Is now an opportunity to minify the core by splitting out some parts and make them into plugins preinstalled with the standard distro?

Anything logical.

Over time ‘core’ has grown.

IMO @jeremyruston needs decide

the balance

between what is essential and what is pluginable.

QED

[dongrentianyu]

I will try to discuss my thoughts here. After the 5.3.8 release, will the next version be 5.4.0? Is it possible to continue some features that are not related to backward compatibility in the 5.3.x branch until the backward compatibility issues are addressed in the 5.4.0 release and then merge them? Or, from now on, do we just wait for the 5.4.0 release to come out before we update other features and release 5.4.1? I’m not in a hurry or trying to rush things; I’m just curious about the future development plan. I’m not sure how much work is involved, so the development team should proceed at their own pace.

[pmario]

@twMat

I can think of a few “semi bells and whistles” but a prime example would be the drawing tool. If TW had not already had one, and it was proposed as a feature today, I’d guess it would be added as a plugin (right?)

I think you will be astonished how view lines of code that actually is. It is 309 loc (lines of code) → 10.5kByte including comments.

• 2/3 of it can not be removed, because it is initialising, loading and rendering of the canvas in edit mode
  • Edit mode is necessary to be able to define type and fields
• IMO rotating an image without modifying it is mandatory and can not be removed
• Resizing an image is needed and can not be removed
• At line 225 the “touch” and “mouse” handling starts
• At line 325 is the save mechanism which needs to stay

So the only code that can be removed or “moved into a plugin” is about 90 locs. If we say the average line length is 50 characters, we can safe 4500 character.

---

• The edit-toolbar has 9 icons. 4 of them could be moved into a plugin.
• 4 toolbar buttons have dropdowns
  • colour picker (used for 2 buttons) … 46 loc → 3kB
  • Opacity dropdown … 32 loc → 1kB
  • Line width dropdown … 25 loc → 1kB
• Icon SVGs
  • Line width → 0.5kB
  • Opacity icon → 1.2kB
  • Paint icon → 0.9kB
  • Eraser icon → 0.5kB

So we can safe: 12.6kByte in the core if we remove the icons from the core. Which means they are not available for users without installing a plugin.

A plugin for 4 icons and 3 wikitext templates and 90 lines of code → IMO that’s not worth it, since core plugins need extra maintenance work.

Especially, since we remove simple very light weight sketching functionality from the app.

---

You are right. Images done wrong can have a huge impact on wiki size. So telling users, how they should use and optimise images, is worth wile. There is a pending PR at GitHub that will make the wiki at tiddlywiki.com smaller by 2000kB.

IMO that’s worth it. Removing basic drawing functionality and winning 13kByte isn’t.

No offence intended.

[twMat]

@pmario

No offence intended.

First off; absolutely no offence taken, on the contrary you are clearly enlightening me with information (and some opinions). Thank you, if anything.

Regarding the unmovable parts in the drawing tool and how 2/3 creates the canvas - but the point is that someone who wants a drawing tool would import one which presumably features the canvas aspects. Those who don’t want a drawing tool also don’t need the “loading and rendering of the canvas”.

BUT, I believe this request was already answered elsewhere where Jeremy explained that supportability is a prime objective in TW and, implied, that it would not be possible to support what I request here. So for 5.4.0 my interpretation is that the answer is “no”.

[Mohammad]

It would be fantastic if the CSS in TiddlyWiki v5.4.0 could utilize modern CSS3, as these features are well-established and supported by all major browsers.

I think both Vanilla and Snow White themes should be retired, and a new minimal, maintainable, and hackable base theme should be introduced, using standard CSS3 rules, functions and classes.

It looks like Jeremy (@jeremyruston) has already begun working on a new color handling code for TiddlyWiki, which will hopefully be included in TW v5.4.0.

[TiddlyTitch]

@Mohammad

I think both Vanilla and Snow White themes should be retired, and a new minimal, maintainable, and hackable base theme should be introduced, using standard CSS3 rules, functions and classes.

Anything to MODULARIZE the CSS in TW would make a lot of difference.

At the moment it is far too difficult to trace which CSS is doing what.
The main stylesheet is too monolithic to use easily.

Two cents, TT

[pmario]

@Mohammad

It would be fantastic if the CSS in TiddlyWiki v5.4.0 could utilize modern CSS3, as these features are well-established and supported by all major browsers.

You need to be more specific here. Which features do you refer to?

There is no CSS3 there will never be a CSS4 – Now CSS Modules have a level.

[TiddlyTitch]

@pmario

@Mohammad

It would be fantastic if the CSS in TiddlyWiki v5.4.0 could utilize modern CSS3, as these features are well-established and supported by all major browsers.

You need to be more specific here. Which features do you refer to?

There is no CSS3 there will never be a CSS4 – Now CSS Modules have a level.

I think, @pmario, you are right.

As far as my use goes the existing TW CSS is very good.

My issue is simple. Vanilla is huge. It is extremely difficult to get good at understanding it.

IMO either modularization OR more logical sectioning by comments would help users a lot,

[XLBilly]

It should be CSS Snapshot 2017, and perhaps also some new CSS properties and functions, because using @support to check CSS properties for fallback is supported in browsers released after 2015.

https://www.w3.org/TR/css-2017/

[TW_Tones]

@stobot

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?

I find this idea both unnecessary and going backwards except to support newer operators in the mathematics space and think another approach could be found that add the functionality without destroying the current approach. But we can have our cake and eat it to.

Why do I say this?. Outside maths operators deduplication actually make sense for regular users. If I build a list from a set of filter runs my intention is usually to build a list of unique tiddler titles then act on each of these once. Uniqueness is something I expect, not an option.

• Filters are primarily for titles of tiddlers and these nearly allways unique

Sure there will be great value in being able to use a filter where duplicates are not removed, but I am not sure why we can’t find a way to set/switch or add a setting to filters to enable this behaviour.

• I understand that every filter that currently does deduplication will need to be changed
• So why not change it to respond to a switch or indicator to that effect?

For example if we are looking at allowing variables to be set inside filters, surly we can introduce one that is interrogated in the filter operators to determine its behaviours, deduplicate or not. This could be set in filters or outside a filter using a pragma or let. this the behaviour can be set for a tiddler, inside the let or as a prefix within a filter.

• Not deduplicating, is the new behaviour to “let users and designers say thats what they want”. No Changes needed unless you want to use the new behaviour. Set it globally, pragma, variable or in filter.
• let it be specifically called out regardless
• perhaps also allow the variable to be set as a paramer \function name(unique:no) filter

eg [set:unique[no]] or [set:unique[yes]] with yes default as is current. This would set the variable “unique” to the value and inside the filteroperators they would respect this.

• In this example the set will not produce or interfear with the titles in the filter
• Perhaps add parenthisis for this (set:unique[no]) or (set:unique[yes]) and allow the value to be a literal, variable or reference. For example (set:pi<pi10>) or more likely (set:places[2]) and later in the filter you can use <places> however you wish. Add the set in a seperate filter run etc…
• Programaticaly in may only be adding the ability for operators to respond to this, if the variable is set, otherwise default. Ans allowing the filter to effectivly act as if wrapped in a $let widget.

[saqimtiaz]

As in indicated in the update of the OP by Jeremy on May 20th, no changes are planned to the handling of duplicates in filters in v5.4.0.