Menu
▾
▴
#965 Shell command substitution on strings highlighted wrongly
On shell scripts, on code like
echo "foo $(bar baz) boo"
the whole "foo $(bar baz) boo" is highlighted as a string. The content of $( ) should be highlighted as code, or at least have a different highlighting.
Another example, on the code
echo "foo $(bar "baz") boo"
Scintilla interprets it as a string containing "foo $(bar ", followed by baz, and followed by another string containing ") boo". This is not what a shell interprets: the right parsing is a string containing "foo <code> boo", where <code> is bar <string>, where <string> is "baz".
Probably the same thing applies for backquoted text.
Also, variables (such as $LANG) should also be highlighted when inside a string.
I forgot to login when adding the artifact, so I'm adding a comment as a signature.
I will accept a patch that implements these but will not be working on this myself.
Also effects heredocs. Single-quoted heredocs should *not* highlight $params, though. These are similar to PHP's "nowdocs". Single-quoted strings also need to ignore them, as they currently do.
This is quite similar (but not identical) to SF bug #1515556, link as follows:
https://sourceforge.net/tracker/?func=detail&atid=102439&aid=3008483&group_id=2439
There are also some test cases in the mailing list file area:
http://groups.google.com/group/scintilla-interest/files
Patches welcome, as Neil says. I'm not going to give myself white hairs by volunteering on this ;-)
While a short patch for just "" nested delimiting is probably possible, users who code like this will be those fond of writing complex expressions, and thus, the patch should handle all sorts of delimiters that nest and the attendant changes in behaviour (like escaping) that follows. Or, if keep the patch more simple, there will be tons of corner cases that these kind of users will run into.
Good luck to anyone who wants to hack at it. :-) [OT] Methinks the bash people should stop tacking more stuff onto a mountain built on piecemeal basis.
Sorry, the correct link to SF ticket #1515556 is:
https://sourceforge.net/tracker/index.php?func=detail&aid=1515556&group_id=2439&atid=102439
I just want to point out that $(...) command substitution isn't one of bash's syntax tricks, but that it's standard POSIX.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03
It's nice because it allows using double quotes without having to escape them, thus making nesting easier.
I'm not sure this sort of stuff can actually be done in Scintilla, I don't recall seeing "nested syntax" such as e.g. coloring $foo or \n or %d in a different color than the rest of the string... in that case this bug would be harder to fix than what I imagined.
I already have most of the behaviour tabulated. Everything can be done. There will be a limited number of nested levels.
The only delay is that I need a big chunk of uninterrupted time to get it sorted out, due to long task switching latency. For various reasons, this has not happened yet. Relax, I'll have a patch ready before the end of the Mayan long count cycle later this year. :-)
By which I mean I plan to tackle recognition of nesting delimiter pairs. The entire thing will still be in the colour of the outermost delimiter pair. I don't have plans to implement multiple highlighting colours.