Variables: Handling separator arguments without escaping

[Taitava]

(I'm not sure if I came up with the best possible title. I can improve it later, if I get better ideas how to summarise this thing.)

From SC 0.7.0 onwards, special characters in variable values are escaped (#11). This is usually a good thing, but there are exceptions, too. Particularly, the separator parameter of {{tags:separator}} variable suffers from escaping.

The {{tags:separator}} escaping issue

Quote from me: #96 (reply in thread)

The design failure is that the separator argument of {{tags:separator}} gets escaped. Everything that a variable outputs gets escaped, and that includes all the arguments that you pass to variables. Right now the only way to solve this problem is to use !, i.e. to prevent escaping of the whole value of {{tags}} (like you did in the next step). I don't know what characters can be included in Obsidian's tags, but if any special characters are allowed, then the workaround might be unsafe.

I need to decide how to fix this:

• Will there be a way for a user to flag that an argument for a variable should not be escaped; or
• Will all arguments avoid escaping; or
• Will there be a way to define value separators using some other syntax than an :argument?

2022-02-07 added comments:

• Will there be a way for a user to flag that an argument for a variable should not be escaped;

No. I think it would be technically hard and unclean to bring the escaping to a level where a variable handle's its arguments. Currently, variable value escaping is done after a variable has generated its value, and a variable has no way to control the escaping in it's scope. It's a clean and simple way, and I'd like to keep it that way.

• Will all arguments avoid escaping;

Again, no, because that would also require moving the escaping mechanism in variable code space. Too messy!

• Will there be a way to define value separators using some other syntax than an :argument?

Yes. More on that below

Possible solutions

I haven't yet had any strong ideas on how I will solve this problem. The above quote contains some ideas, but I need to think about them more.

2022-02-07 I got one idea that is described in #147. This discussion #105 will concentrate on developing ->join() method.

[FelipeRearden]

Just to inform that I did the same test on version beta3 and it's working the same as in version beta2 :)