%{-expansions in " should allow unescaped " #1048

Open
kballard opened this Issue Dec 20, 2016 · 5 comments

Projects

None yet

3 participants

@kballard
Contributor

If I have a %{-expansion nested inside a double-quoted string, it appears that I have to escape the double quotes in the expansion too. My guess is the parser is picking out the double-quoted string without knowing about expansions, and then after the fact it's parsing that string for expansions. But this is annoying, and the grammar is still unambiguous if you fix this.

For example:

:echo "%sh{ echo "hello world" }"

This looks like it should work, but instead it produces

parse error: 0:3: unterminated string '%sh{...}'

FWIW, the README describes %sh{ expansion as being similar to POSIX shell's $(), but the latter handles nested quotes correctly.

@lenormf
Contributor
lenormf commented Dec 21, 2016

Token expansion and string parsing don't work like in a shell, e.g. %sh{ printf '}'} will return an error. It's not the most convenient and has pretty much been improved upon since forever, and I guess it could change again in the future, but implementing only your suggestion would not be logical with the way things work generally (c.f. my example). Having a shell-like parsing entirely would probably be better.

@kballard
Contributor

Parsing shell syntax would be great, but I didn't advocate for it specifically because it adds significant complexity. What I'm suggesting is much simpler and I think perfectly in line with the intent of the current string rules (e.g. that you can nest certain types of strings inside others). My example used %sh{, but you can reproduce it with just %{, e.g. "%{"foo"}". I used %sh{ because it's a good example of where you might expect to see nested quotes. In any case, the way the rules currently work, having an unescaped double-quote inside a nested "%{ is completely useless, because it's guaranteed to throw an error, and so the requirement to escape it is just annoying and unnecessary.

@mawww
Owner
mawww commented Jan 5, 2017

I'd really like to migrate the command parsing to something closer to the shell, however there is still one big problem: %sh{ ... } must be able to expand to multiple commands, $(...) does not.

echo $(echo aaa; echo bbb) outputs aaa; echo bbb, In Kakoune we need that to output aaa\nbbb and to treat that output as separate commands.

In other words: yeah, thats an issue, we need to improve that, but unfortunately we cannot just use the shell parsing model.

@lenormf
Contributor
lenormf commented Jan 8, 2017

echo $(echo aaa; echo bbb) outputs aaa; echo bbb, In Kakoune we need that to output aaa\nbbb and to treat that output as separate commands.

This might be a bug of your shell, there's no reason why it should consider the contents of a subshell as a single command and not perform regular command parsing (splitting the command in two parts, using the semicolon as a delimiter). The command you're giving as example works as expected in zsh, printing aaa bbb, also using a built-in command as example is tricky as it's implementation defined and we avoid those in kakoune scripts anyway.

@mawww
Owner
mawww commented Jan 8, 2017

Sorry, the command should be echo $(echo 'aaa; echo bbb') the output of $(...) is not reparsed,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment