Delimiting quotes in $Text assignment

I would like to set the $Text of a template programmatically. Works fine apart from one wrinkle: I want the text to include double quotes within the value. I’ve tried delimiting it with a \, but no joy. So simplest example would be something like this…

$Text("/Templates/Preview")="I want a string like this \"HTML\";";

And yes, Smart Quotes is off. :wink: I tried double-delimiting, ( \\\"HTML\\\") even though that doesn’t make sense, and using html entities in case it was that.

What am I doing wrong?

Use single quotes:

$Text("/Templates/Preview")='I want a string like this "HTML";';

Strings can be delimited by either paired single or double quotes. Double are the norm, but this is an occasion where single quotes are required. See more.

1 Like

I’m curious, can single quotes be escaped? When using double and single quotes in a string literal, what is the escaping convention?

D’oh!
I swear I thought I’d tried that :man_facepalming:
Thanks Mark

Firstly, Tinderbox follows general conventions but in its own manner to asking oneself is it like C, Python, whatever, is likely not a good start.

In Tinderbox’s original incarnation, in 2001 [sic], action code strove to be quite loose: write what you mean and the app will parse the meaning. So you might write:

Color = blue

or

MyString = O'Driscoll

But by c.v4.5.0 (August 2008) as action code grew in complexity, added dot-operators, subsumed query syntax, and—via value() and ^value()^—subsumed use of much of export code operators the old looser syntax was deprecated in favour of more explicit encoding:

$Color = "blue";
$MyString = "O'Driscoll";

Note: the old forms still work. At least they do if simple code. But being deprecated syntax/usage, if they fail, the user will need update their code.

Why this ambiguity of usage? Several reasons. Firstly, Easgtate has a commendable track record in not breaking old automation. Not everyone has a coding background and many have action code that is once-and-done. Make it and then never touch again. Vicariously breaking that just for new features plays out differently for new vs. long-term users. Not everyone wants to, or knows how to, fix/updates old code.

So what might seem like thoughtless ambiguity for the new user of the app, is quite the reverse. Thoughtful consideration fo the long haul.

Most notable in the newer examples is the enquoting of 'literal string values: in plain terms, pieces of actual text as opposed to operators, variables, etc. ‘Straight’, not typographic ‘curly’ quotes, are used. These can be matched pairs of single or double. General convention—but not a requirement—is to use double straight quotes, only using single quotes where it is necessary. But you are free to choose. One matched pair can enclose uneven number of the other type:

$MyString = "The title '"+$Name+"' is used for this note";
$MyString = 'The title "'+$Name+'" is used for this note';

The above both work albeit one outputs the title in single quote and on in double quotes.

So far, so, goof, by what about escaping. In literal strings (and some string-based attribute inputs), a backslash before a character implies “use this characters and not its special meaning” (e.g. for regex, etc, etc.). But…

Tinderbox does not allow escaping of straight single or double quote characters.

So, for complex scenarios—that most will likely not encounter—you may need to use an approach like the last example above or to park strings into string-type variables as you build what would otherwise be complex use of differing quote types. Also, if the quotes are in literal text, these days (with unicode!) if you actually want, or could use, typographic single/double quote in literal text, do so!

Does this give enough detail or do you have a deeper question?

HTH :slight_smile:

[sorry for the long answer, I’ve a sense the eventual outcome might be a new aTbRef article]

1 Like

In the future, I plan to support an operator string(abc), which returns “abc” as a quoted string. This works around the problem of quotation marks in strings. It leaves the problem of parens in strings, but those don’t cause trouble in quoted string.

If you have both parens and quotation marks in your string, it’s still bad. But you can copy the text from any attribute.

2 Likes

I should have illustrated the latter point by updating my earlier example of;

$MyString = "O'Driscoll";

to use a typographic quote:

$MyString = "O’Driscoll";

straight/typographic quotes are a problem. Code parsers doesn’t interpret typographic quotes as string delimiters, but for display we tend to prefer typographic quotes. Markdown interpreters—as used by this forum’s software—‘help’ by assuming all quotes are intended as typographic except within Markdown code blocks. Of course, those most likely to have code confusions likely also don’t understand optional Markdown such as to indicate code. :frowning: See what mmd does to the following code sample:

  • code with additional Markdown markup: $MyString = "O'Driscoll";
  • same without additional markup: $MyString = “O’Driscoll”;

Aside from the font and background colour, note how in the second example the forum software–not the user—has mangled the code by changing the type of quote characters.

In addition, in a lot of fonts the two types of quotes both look the same which is … unhelpful.