#1794 Update to LexBash to support zsh #-related highlighting glitches

Bug
closed-fixed
5
2016-01-18
2015-12-19
No

This update adds some zsh support to LexBash, specifically zsh #-related highlighting glitches. Turns out there are a multitude of cases where zsh uses the # character not as a comment line start. The recent Scintilla list discussion was unhelpful in the sense that a zsh proponent should have properly idenfitied and catalogued the various zsh syntax before suggesting solutions.

(a) Improved highlighting for zsh [#base] and [##base] syntax in arithmetic expressions
(b) Support for zsh #name, ##x and ##^A syntax in arithmetic expressions
(c) Support the use of the # character in zsh glob syntax using a heuristic

The changes does not appear to be too disruptive to bash highlighting, hopefully folks don't put comment lines in those places or such fashion. Attached LexBash.cxx and some test cases.

1 Attachments

Discussion

  • Neil Hodgson

    Neil Hodgson - 2015-12-20

    Committed in [87286d].

    The lack of rigor in language documentation is regrettable.

     

    Related

    Commit: [87286d]

  • Kein-Hong Man

    Kein-Hong Man - 2015-12-21

    Here is a revised LexBash.cxx for the ##a and ##^A. My apologies for messing up these tests.
    In the earlier patch, the ##a would appear to shade the ##^A test.

     
    • Neil Hodgson

      Neil Hodgson - 2015-12-21

      Committed [888872].

      I don't see this making any difference to the output since the upper-case character following ##^ is an identifier anyway.

       

      Related

      Commit: [888872]

  • Kein-Hong Man

    Kein-Hong Man - 2015-12-21

    You're right, serves me right trying to fix it in a hurry. Now the following ##a allows non-conforming ##^A whereas previously the ##a case shadows the ##^A test entirely. So highlighting is a little relaxed and it won't disallow things like ##^1 assuming ^A are ASCII control chars. Which is just as well, leave the highlighting a little relaxed, in which case the ##^A can be deleted entirely if you are so inclined.

     
    • Neil Hodgson

      Neil Hodgson - 2015-12-21

      I'd leave the code in its current state. They are separate cases to match and ending them accurately may be more robust with future changes.

       
  • Neil Hodgson

    Neil Hodgson - 2016-01-18
    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks