[TW5] [Plugin] Sortan: For sorting alpha-numericals

[Riz]

plugin and demo


Currently available sort filters in the core either sorts alphabetically or sorts numerically. It creates an issue when both alphabets and numbers appear in the titles.

For eg: Apple 8, Apple 9, Apple 10 will be sorted as

Apple 10
Apple 8
Apple 9


With sortan, you can sort them as

Apple 8
Apple 9
Apple 10



As usual, there is a sortancs filter too for case-sensitive option, and both are negatable (ie, using them as !sortan will sort them in decreasing order)


I was very tempted to make a pull request to modify the current sort filter instead of creating a plugin. I had a feeling that such a change will not be backward compatible.

Anyhow, let me know what you feel,

sincerely,
Riz

[Stephan Hradek]

VERY COOL!

I like it. Should be part of the core.

[David Gifford]

I second this, or an adaptation of this, becoming core.

[David Gifford]

Added to the 'Lists and filters' section of the TiddlyWiki ToolMap https://dynalist.io/d/zUP-nIWu2FFoXH-oM7L7d9DM

[@TiddlyTweeter]

Ciao Riz

My feeling is YES regarding sort orders in core, if viable backwards compatible.

IMO its currently a serious hassle in TW we lumbered with a counter-intuitive, cumbersome default sort order.

Best wishes
Josiah

Riz: I was very tempted to make a pull request to modify the current sort filter instead of creating a plugin. I had a feeling that such a change will not be backward compatible.

Riz wrote, fully:

[BurningTreeC]

this is great!

can't we try to make a pull request to add it to the core as a new filter?

BTC

[Riz]

I wanted to have a discussion first before making a pull request. It is painfully easy to convert the existing sort filter to acquire this behavior. Case being that, should we have it as a new filter, or modify the existing sort. Right now I feel like we ll have to add it as a new filter, as modifying existing sort might break the work flow of those who depended on the current way of its behavior. If somebody tells me different, Either way I would be happy to oblige.

[BurningTreeC]

I wanted to have a discussion first before making a pull request. It is painfully easy to convert the existing sort filter to acquire this behavior. Case being that, should we have it as a new filter, or modify the existing sort. Right now I feel like we ll have to add it as a new filter, as modifying existing sort might break the work flow of those who depended on the current way of its behavior. If somebody tells me different, Either way I would be happy to oblige.

Yes, as I understood it, this is how it is - to assure compatibility for those filters you appear to need to add yours as a new one

I would like to have both - compatibility and your new filter, that's why I personally don't bother if it's almost the same as the original sort filter