[TW5] How to check a tiddler's title (not) ending with a certain postfix?

[TheDiveO]

TW5 is a godsend hacking-wise and also an architect's dream of modularity. As I'm customizing TW5 to my specific needs I note down what I did in documentation tiddlers. These doc tiddlers accompany the customization tiddlers. The documentation has the same title as the tiddler but with "/doc" appended. I also wrote a tiny info tab tiddler that displays such documentation and allows to easily create or edit existing documentation.

Now I would like to cut out doing documentation on documentation. That is, when you open a doc tiddler you get yet another doc info tab and could then create documentation on documentation.

So ... how do I find out if the title of the current tiddler doesn't or does end in "/doc"? In TW5 markup, that is? I would like to not resort to JavaScript for this task but so far I could not come up with suitable filter operations to achieve my goal...

Any help...?
Thanks!
-- TheDiveO

[Jeremy Ruston]

Hi TheDiveO

For 5.0.16 I've added new suffix and removesuffix operators that I think will do what you need:

https://github.com/Jermolene/TiddlyWiki5/commit/dcf4e93a3283e3e93cc14e50366f9b0252870835

https://github.com/Jermolene/TiddlyWiki5/commit/2e3221c4e0e8f4b2af5e6be4b9d04569e1bceda1

As a workaround for the moment, you may be able to use the regular expression filter operand syntax. For example, this returns all tiddlers whose titles end with "beta":

[field:title/beta$/]

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[TheDiveO]

Ah, I've completely missed the regexp trick ... yes, that's workable.

I've hacked in a removepostfix operator quickly myself and then noticed that most filters at this time are actually case insensitive. For my use case I need case sensitivity though. So I would like to ask for this to getting added to; maybe as the "cs" (case sensitive) variant as sortcs already does.

Anyway, thank you very much!
-- TheDiveO

[TheDiveO]

...case sensitivity for "prefixcs", that is. (And not for all filters as my previous post might sound like.)

[Jeremy Ruston]

I've hacked in a removepostfix operator quickly myself and then noticed that most filters at this time are actually case insensitive. For my use case I need case sensitivity though. So I would like to ask for this to getting added to; maybe as the "cs" (case sensitive) variant as sortcs already does.

Hmmm I think it maybe a mistake that the prefix/suffix operators are case-insensitive. For 5.0.16 I've changed them to be case sensitive. If people want to use a case insensitive version the workaround would be to use the regexp approach.

https://github.com/Jermolene/TiddlyWiki5/commit/112a9a95d95e9f62f110c97a4faaf537c5c100b1

Best wishes

Jeremy.

 

Anyway, thank you very much!
-- TheDiveO

[TheDiveO]

Yes, it makes more sense this way.

Thank you for the feature upgrade!
-- TheDiveO

[Stephan Hradek]

Regarding case: How about a general filter operator which defines case sensitivity?

My proposal would be to look what Applescript has: http://books.gigatux.nl/mirror/applescriptdefinitiveguide/applescpttdg2-CHP-19-SECT-6.html

So to see whether a title ends with "/doc", ignoring case, and starts with "Tech:", not ignoring case, one could then write:

[ ignoring[case] suffix[/doc] considering[case] prefix[Tech:] ]

Instead of "case" one could also use (combinations of): case, punctuation, whitespace, hyphens (The other examples in AppleScript, I don't know whether they are implementable).

[Jeremy Ruston]

Hi Stephan

Interesting idea. My concern would be that these new directives are indistinguishable from filter operators, and yet don't behave in the same way. There's some attraction to the consistency of all filter operators performing filtering.

The other concern would be that each filter operator would need to explicitly support the required directives.

I guess the question might be whether there are use cases that can't be satisfied with a regexp filter (given that regexps can do the examples you mention from AppleScript).

Best wishes

Jeremy.

 

[Stephan Hradek]

Am Donnerstag, 28. August 2014 17:36:05 UTC+2 schrieb Jeremy Ruston:

The other concern would be that each filter operator would need to explicitly support the required directives.

Except if you give us JavaScript comparators which support them. So instead of comparing 2 values with "<", ">", "==" etc. we'd either have a comparator for each of those or  a function:

compare( operand1, operator, operand2 )

where "compare" would "unify" the operands and give the result of the comparison defined by the operand - where this operand could as well be a function, maybe?

All filter operators need to be changed, agreed, but they need not explicitly support the directives. Especially when later other directives might get introduced.