Idea: Enhance the length operator

That is not clear from the title or the OP. I asked for clarity earlier, and all I got after it is a sense that you are still pursuing what is in the OP. If that’s not the case, then I’m fine. Clarification a little earlier would have been a time saver.

What may seem trivial on the surface isn’t. I’ve seen that kind of thing before, and it causes headaches. Keep the implementation code clean and focused.

It is necessary. I refer to the TW documentation a lot. Maintaining focus and constantly filtering out the things that I don’t want to see and don’t want to use gets exhausting. So I rely on the TW 5.2.3 documentation because it does not have the clutter, and I use TW 5.2.3 because it is a 1 to 1 match with the documentation. That helps me not get distracted, to stay focused. I’m already dealing with sensory and cognitive overload 24x7, so I need to minimize that wherever I can, and so TW 5.2.3 (and no version after it) helps a lot.

I immediately took to TW when I first started because it works the way I think, which helps me tremendously. All new features added after TW 5.2.3, they do not work the way I think, and they frustrate me. So I stick to what works as I think.

If and when I do contribute anything, I do remind folk that I’ve done those things as per TW 5.2.3 in case they might prefer adjusting the contribution with the more current features. Yet another failure at coherent and concise communication, I apologize. It is impossible for me to cognitively keep up with the Joneses, and it gets frustrating. Time for a break.

I had a look at the code but did not test it yet. It looks good. There are 2 things which probably would prevent it from being in the core.

  • I think the name needs to be discussed. because from the description it’s primary function is returning tiddler lists
  • Completely changing the behaviour if a parameter is present or not violates the principle of least surprise.
    • This could also lead to real problems if used like this: [stringlength<variable>]
    • If the variable becomes empty it will return numbers instead of strings and vice versa.
    • hence the problem with the name

As I wrote completely changing the behaviour has a high chance to cause problems.


For filtering title lists I personally would want [titlelength:gt,gteq,eq,lt,lteq[5]] for greater-than, greater-or-equal … Where only 1 operator suffix is possible and “eq” would be the default if there is no suffix.

My question is what would be wrong with [titlelength:gt[5]length[]] to return number, instead of changing the behaviour of stringlength based on the parameters. – As I wrote the name itself needs to be discussed.

just some thoughts

I think there may be other ways to handle this so I am keeping an open mind however I do not personally have a problem with the use of length[] and length[n] because they both relate to length and if not specified length[] finds the length, if specified length[5] filters it based on length.

  • This is a personal preference so I am not proposing it for the core.

There may however be a compromise and I am still researching ideas around extended string handling. I understand the argument against it, and thats fine, however for myself even I find it logical, satisfying and frugal.

  • A compromise may be has.length[] and get.length[] custom operators.
  • Perhaps then has.length[gt],[4] or if one parameter has.length[4] (default to eq)
    • I like you titlelength if it defaulted to eq but its nice to have the opportunity to paramterise the comparison (although not essential)

One issue is to have a native filter operator OR a custom operator because much of this can be done in a macro or procedure, but they need to be evaluated (wikify) which becomes an issue. This is not the case for custom operators or native operators.