Menu
▾
▴
#990 Bash lexer: one-character command-line options
Bash lexer incorrectly highlights one-character short command-line options as SCE_SH_WORD. Idea behind that is to highlight "file test operators" inside test expressions [ ... ], but the lexer is too silly to distinguish them from ordinary command-line options. As for me, highlighting file test operators is not so useful, and wrong highlighting of options is annoying. If it isn't desirable to drop this highlighting completely, Scintilla may introduce additional property to turn this behaviour on/off, or an additional style so that user can turn the highlighting off by "resetting" this style. It would be nice if the highlighting was disabled by default.
Patch to completely remove highlighting of file test operators
It would be nice to be able to disambiguate those different things, but apart from that, I have no other opinion and I'll leave the patch to Neil.
I wrote the bash lexer (actually split perl and bash lexing) because an improved perl lexer was breaking too many bash script highlighting; and as the only thing I ever do with bash is to tweak shell scripts, I am most happy to leave the bash lexer to knowledgeable contributors.
I agree that the two cases should be differentiated but do not want to drop current test operator recognition as that could be seen as a regression by anyone depending on it.
I attach a new patch. This one adds property "lexer.bash.highlight.file.test.operators". Default value is 1 (highlighting is turned on).
Alternative patch: add a property to turn the highlighting on/off
Okay, I take back my words, I do have reservations after checking "man bash". Perhaps Eugene could explore doing it without adding a new property. Adding properties is the easy way out (in this case, passing glitches to the user to pick their choice), and it is not something I would do if it is possible to fix this thing in the lexer.
Conditional expressions involve [[...]], [...] and test ... Since shell scripts are line-based, I think we are dealing with [[...]], [...] delimiting on a single line, and test ..., which may also be involved in compound commands, I suppose. At first glance, getting this done does not seem impossible...
What if you added a separate style for test operators?
Users could set it to match the default style, which would
effectively "hide" the current behavior. Having the ability to
specify the test operator style could be considered an advantage,
no matter if the lexer ever gets fixed or not.
When it was part of the Perl lexer, file test operators was lexed in the keyword style. I just retained the thing. Arguably, it can be thought as a special function or command. Alternatively, one might think they should be operators.
But "-x" is parsed as a bareword in Perl for some things like hash definitions, so I get the feeling that historically it is seen as a word of some sort -- and thus, being special words, file test operators highlighted as keywords is perhaps an accurately rendered throwback to an era when scripts of the shell-like kind were just simple batch files.
I would rather not have extra properties if it can be done transparently to the user. I'm not sure if it warrants an extra style -- I don't think it does, but I'll leave any contributed patches of such nature for Neil to decide upon.
In any case, if you want a separate style, you would still need to differentiate command options and file test operators; if not, the ambiguity is still there and it would still be a case of pushing more unnecessary complexity to the end user.
With a FLOSS project like this, we are not so much bound by tight deadlines or forced to select quick fixes, so I think high-quality solutions are worth exploring.
Sorry, that last post was me, for the record. My bad.
Eugene, if you're not hacking at the LexBash code now, I will spend some time on it in the very near future. Will try to add some state vars to split lines into commands, then we can proceed to do the disambiguation we need (and pave the way for other more detailed or precise highlighting, if needed in the future.)
It would be nice. I don't have free time for Bash lexer now.
Eugene, an update for LexBash that should fix the issue has been posted to:
https://sourceforge.net/tracker/?func=detail&aid=3033135&group_id=2439&atid=352439
If you find any significant breakage with the update, please report it and I'll see to it if it is not too difficult to fix.
Committed update.
Thanks for the patch. The bug is fixed now.