Add a separate lexical convention for strings of uninterpreted JavaScript

[ELLIOTTCABLE]

This requires some effort to do well, I think.

The idea is to support a form of "string" argument, that doesn't conflict with JavaScript's lexical conventions — i.e. that won't require the user to double-escape all actual JavaScript-string-related stuff inside a chunk of JavaScript. Like, this is nasty, even though it'd work by the lexical conventions of our own strings:

alias editor_rm (editor | jsb -p 'tri.native.run(`rm -f \'${JS_ARG[0]}\'`)')

On one end of the complexity spectrum, we could define a new, non-traditional delimiter-character that's not commonly used in JavaScript expressions of interest to our users (~, for instance), and treat that as a boundary to "uninterpreted strings".

alias editor_rm (editor | jsb -p ~tri.native.run(`rm -f '${JS_ARG[0]}'`)~)

(Of course, I'd love to use something like `backticks`; but that'll conflict with ES6 template-strings ... which coincide nicely with a lot of Tridactyl tasks, so I definitely don't want to make that a high-friction usecase.)

Meanwhile, at the far end of that spectrum, we could try and precisely reproduce JavaScript's own lexical conventions for strings — that is, our code becomes JavaScript strings, and you escape our string-like lexing "back" to JavaScript lexical conventions in exactly the fashion users are already used to:

alias editor_rm (editor | jsb -p ${ tri.native.run(`rm -f '${JS_ARG[0]}'`) })

I feel like something along those lines is the most user-friendly option (not exactly as presented, obviously some more thought is required); but it'd be far more complex to implement in a way that doesn't end up tripping the user up. (We'd want to handle nesting, escaping, etc exactly as the underlying JavaScript engine does, as much as possible — while still allowing ourselves to control/delay evaluation of the nested JavaScript segment.

[cmcaine]

How about: jsb`console.log(`some template ${PIPED}`)` ? That matches the tagged template strings syntax. It requires all internal backticks to be escaped, quoted or balanced, which JS also requires. Which is also the same issue we'd have with braces or whatever.

[ELLIOTTCABLE]

Wait, I'm missing something — maybe it didn't translate through e-mail? Your example includes non-escaped backticks, over here.

Meanwhile: my goal here would be some literal-form for JavaScript and shell strings, that doesn't conflict with existing backticks, single-quotes, or double-quotes — i.e. that would require no escaping for common constructs, even if they're somewhat complex. (Look at the above example from the docs, for instance: JavaScript and bash, nested, are thus already ‘fighting eachother’ for lexical control, so to speak. I'd love it if our language could be agnostic of those concerns.)

tl;dr I think long-term user friction trumps initial user surprise, here, re: introducing an additional/new syntax. Also, whatever I lex, this is still effectively just a shell-word; so it's not a replacement for simpler constructs (foo is still fine, "foo bar" is still fine — you'd only need to reach for, say, ~, if you wanted ~to.do(`something "--really=${complicated}"`)~ that already involves nesting multiple languages.

[cmcaine]

I was trying to suggest we use backticks but just require the internal fragment has escaped or balanced backticks inside.

Some obscure character is also fine by me. Unicode is an option.

${} is an option, and sounds about as difficult as backticks to me.

[ELLIOTTCABLE]

One very vim-y thing, would be allowing user-definiable quotation characters to avoid delimiter collision. Wikipedia describes this as “multiple quoting”, although I don't find that very descriptive; Vim does this with particular commands like :s, allowing both :s/a/b/ and :s_/_//_ or whatever else you can think of.

How do you feel about introducing ~ or the letter q or something as a "quotation introduction", that must then be followed by another character that becomes the quotation delimiter? I quite like the idea, and it feels extremely Vim-y to me.

alias editor_rm (editor | jsb -p ~@tri.native.run(`rm -f '${JS_ARG[0]}'`)@)

[cmcaine]

That's an interesting idea, I'd rather the simpler options described above unless there's a clear use case, though.

Up to you.