#990 Bash lexer: one-character command-line options

Bug
closed-accepted
Neil Hodgson
Scintilla (792)
3
2010-07-30
2010-07-11
Eugene
No

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.

Discussion

  • Kein-Hong Man
    Kein-Hong Man
    2010-07-11

    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.

     
  • Neil Hodgson
    Neil Hodgson
    2010-07-12

    • assigned_to: nobody --> nyamatongwe
    • priority: 5 --> 3
    • status: open --> open-accepted
     
  • Neil Hodgson
    Neil Hodgson
    2010-07-12

    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.

     
  • Eugene
    Eugene
    2010-07-12

    I attach a new patch. This one adds property "lexer.bash.highlight.file.test.operators". Default value is 1 (highlighting is turned on).

     
  • Kein-Hong Man
    Kein-Hong Man
    2010-07-12

    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...

     
  • Jeff Pohlmeyer
    Jeff Pohlmeyer
    2010-07-12

    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.

     
  • Kein-Hong Man
    Kein-Hong Man
    2010-07-13

    Sorry, that last post was me, for the record. My bad.

     
  • Kein-Hong Man
    Kein-Hong Man
    2010-07-16

    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.)

     
  • Eugene
    Eugene
    2010-07-16

    It would be nice. I don't have free time for Bash lexer now.

     
  • Neil Hodgson
    Neil Hodgson
    2010-07-23

    Committed update.

     
  • Eugene
    Eugene
    2010-07-23

    Thanks for the patch. The bug is fixed now.

     
  • Neil Hodgson
    Neil Hodgson
    2010-07-30

    • status: open-accepted --> closed-accepted