More direct way to insert "[[" and "]]" in filters

#1

In another thread, fellow @Charlie_Veniot posted this as part of something:

\define lBs() [[
\define rBs() ]]
<$button set="About!!tags"
 setTo={{{ [[About]tags[]!match[Mytag]addprefix<lBs>addsuffix<rBs>] 
<SNIP>

Anyone who’s been around a while has seen this workaround to be able to use bracket characters in the filter. But those separate macro defs are obviously cluttering so I’m wondering if there is a more direct way?

It “feels” like there should be some escape characters? Otherwise, how about introducing this?

Or maybe filter ops addleftbrackets[]…addrightbrackets[] or perhaps addbrackets[left], or addsuffix[leftbrackets]?

Thoughts?

1 Like
Dynamic Filters
#2

See charcode and format operators:

https://tiddlywiki.com/#charcode%20Operator:[[charcode%20Operator]]%20[[format%20Operator]]

#3

Whatever makes it easier for you to read in your code. I am not crazy for escape characters, and usually go with something I can remember (left Brackets, right Brackets, and then the actual brackets in the macro), but we are all cognitively wired differently.

You’ve got to go with what you remember best.

All of that said, this would have been such an awesome opportunity to try out A collaboration experiment: code and documentation (Link in original post was incorrect, see edit below)

EDIT: copy+paste got wonky: proper link to A colloboration experiment: code and documentation is A collaboration experiment: code and documentation: https://groups.google.com/g/tiddlywiki/c/Y8WOsSoJuek

#4

@saqimtiaz - thank you, I did not know about that operator. However it doesn’t seem to be a constructor adding the character, right? Only detecting if the character exists.

#5

Hm, IMO it is more a question of writing succinct code. IMO it is obviously better if brackets can be pre-/appended directly in-filter. Put in another way; it would be very bad if we, in filters, were forced to generally split out filter operator arguments.

@Charlie_Veniot - that link leads to here, so I’m guessing it is the wrong link.

#6

Side-track question: for the [tag[TableOfContents]format:titlelist[]] example, why are there two results in the list with double brackets around them? Is there an issue with how “titlelist” works ?

EDIT: or maybe the example needs a bit of a more substantial use-case example. I can’t imagine any value in the as-is list that results from that filter.

#7

Succinct code that causes me to think “what is that” is not succinct at all. It causes me confusion.

So succinct is different for different folk. What you may think is good for me is horrible, and what is good for me is not necessarily good for everybody else.

Hence: you have to choose what works for you. If you are working on something with a team, then each of you make your case for what is best, and everybody must suck it up for the most popular choice.

So better for you, go for it. We just can’t assume that each of our medicine will fix things for everybody.

Just saying.

But I do always keep an eye out for something better. Just haven’t seen anything that works for how my mind works. (Yes, attention-regulation disability, among other things that make it challenging for me to process what I see, so I am an extreme case.)

ADDITION: it sometimes takes more verbose code for me to interpret what is going on. Succinct often feels cryptic, in the sense that I don’t understand what I’m looking at.

#8

That’s a couple of times now that a Google Group link I copy and paste here turns out as a link to the very thread I’m posting in. Very strange. Could just be me showing my age…

A collaboration experiment: code and documentation: https://groups.google.com/g/tiddlywiki/c/Y8WOsSoJuek

#9

@twMat
I use two more similar solution in my work

  1. I use a utility tiddler contains all type helper macros, so I use the same method as you given above but I use a helper central tiddler

  2. I also use the below macro

\define makeTitle(title) [[$title$]]

...

\define makeTitlev()  [[$(currentTiddler)$]]

Now from 5.2.0 I got used to format:titlelist[]

This construct is also used

<$vars lb="]]"  rb="[[">
....addprefix<lb>addsuffix<rb> ....
</$vars>
#10

You don’t specify which operator you are mentioning, though neither of the ones that I linked are used for detecting anything.

If I understand the goal of your code correctly, this is how I would approach the issue of brackets:

[[About]tags[]!match[Mytag]format:titlelist[]join[ ]]

1 Like
#11

Title List documentation: https://tiddlywiki.com/#Title%20List

1 Like
#12

I’d sure like to be able to say it makes sense to me, but I don’t get it. No worries, I’ll just keep doing what I’m doing.

#13

@twMat

My current Work around is;

I am yet to make it a permanent practice with all my wikis but I have made a global macro with all such additional strings [[, ]], {{, }}, eg `\define pipe() |" with the intention to create a bookmarklet I just click to add to any wiki .

An alternative to using such macros so any special character can be escaped at least inside filter operators as others have suggested would be nice.

  • One could imagine parenthesis eg; split(|) instead of split[|] or split({{) where the content is considered liberals and “removed” before the filter is parsed and replaces with hidden variables.

However I have wondered if we could build a simple global macro with a preset set of named variables for these special characters - basically making the variables part of the core and standardised so we need not define them and we all use the same names.

If you wanted to get cheeky you could define this;

\define ❴() {
\define ❴❴() {{
\define ⟦⟦()  [[
\define ⟧⟧() ]]
then use  <<❴>>  or <❴>  in filters
 <<⟦⟦>>  or <⟦⟦> 
 <<⟧⟧>>  or <⟧⟧>

The macro or variable name is actually a similar looking Unicode character not an actual open dbt square or curly bracket and is replaced with the “real thing”.

The problem is, these are not easy to insert from the keyboard, but perhaps if we had an editor toolbar button with a drop down to insert these macro names/symbols from a list it would be easier. But this would be equally helpful with named global variables eg the option “| pipe” inserts <pipe> or <<pipe>> which is defined as “|”.

Regards

2 Likes
#14

This solves the actual problem that I’m trying to overcome in my OP. Thank you @saqimtiaz .

#15

Adding my two cents here, though realize @twMat’s question is solved.

First of all, titlelist[] is fantastic and has reduced the need that Mat originally identified, though I will mention that if the title to be formatted doesn’t contain a space, the brackets are not added, which is usually fine, but depends on the scenario.

I have had similar thoughts to @TW_Tones regarding some global macros. While you can generate characters using the new charcode[] operator, you can’t really use/combine them (other than using charcode[] in a variable outside the list and then referring to it). Because of that I’ve also thought that either some escaping within filters or global macros would make sense. For example if I want to search[] for [[,or append-prefix[], the [[ you can’t really do it.

Escaping somehow would be nicest as you could do regex strings without variables/macros, but global macros would be neat too - and including newline! I don’t know if I’d personally go for the unicode characters as they’re not easy to enter, but a <lb>, <rb>, <newline> are things I still do a lot of, and if they were based in it would seem to make sense.

#16

There’s a risk of confusion, but we could add a charcode macro that could be used like this:

[get[field]addprefix<charcode 93>]
[<currentTiddler>addsuffix<charcode 13 10>]

We could also add support for the standard names for control characters:

[<currentTiddler>addsuffix<charcode cr lf>]
4 Likes
#17

Great idea! That’s a bit more consistent actually.

#18

Actually Just before, I read Jeremys suggestion I recalled we can include parameters with macros in filters now so but we can explore designing macros to support this. Basically the sky is the limit. I will do some experiments.

I do like the idea of standard names for control characters.

As Jeremys example hints at, we often need these special characters concatenated to dynamic values prefixing etc… so I see some value exploring this a little further to come up with a really exceptional solution.

In the mean time it would be good if;

  • we had shorter forms of add/remove prefix and suffix
  • Allow Unicode to be me more readily used in filters.
  • A method by which to wikify a variable within a filter

Eg replace

<$wikify name=varname text="input wikitext">
{{{ [all[]prefix<varname>]] }}}
</$wikify>

with something like the following (choose correct delimiters)
{{{ [all[]prefix(<varname>)]] }}}
in this example the parenthesis says first wikify varname avoiding the wikify widget complexity.

#19

I think it would be more natural with an operator suffix, e.g

addprefix:charcode[93] and addsuffix:charcode[13 10]

#20

How would that work with filter operators that already have a suffix defined?