#1778 Some characters are not recognized as being part of here delim

Bug
closed-fixed
5
2016-01-18
2015-11-13
Philippe A.
No

I have been redirected here after first reporting the issue in Notepad++.

Currently, an HERE DELIM must start a letter. If it starts with any other char, the here block will not be highlighted properly.

This is very unfortunate, because I would like to document bash scripts with perlpod, like this:

cat<<=cut
perlpod
=cut

Vim always highlights the here block correctly regardless of the here delim validity. I suggest to use the same approach.

From bash perspective, here are some examples of valid and invalid here delim. This is not exhaustive.

accepted
=cut
!cut
:cut
*cut
]cut
[cut
$cut

rejected (bash syntax error)
<cut

cut
;cut
(cut
)cut
&cut

Thanks.

Discussion

  • Neil Hodgson

    Neil Hodgson - 2015-11-15
    • labels: --> scintilla, lexer, bash
    • status: open --> open-accepted
    • assigned_to: Neil Hodgson
     
  • Kein-Hong Man

    Kein-Hong Man - 2015-12-09

    I will take a stab at fixing this during the Dec holidays. Simple whitelisting of some symbols is a quick fix solution, but I am looking at isolating the arithmetic << from interfering with the HEREDOC << so all legal symbols work in HEREDOC delimiter words.
    A test file is attached, I have tested this on Cygwin bash 4.3.

     
  • Kein-Hong Man

    Kein-Hong Man - 2015-12-21

    In testing of Cygwin bash, it appears that << in HEREDOC form is illegal in arithmetic expressions, and << in arithmetic shift form is illegal outside of arithmetic expressions. So we can probably move further away from LexBash's dual shell/perl roots and disambiguate << using the existing BASH_CMD_ARITH state, and now for example HEREDOCs using a number as the delimiter word will be HEREDOCs.

    However, there is a potential issue with the csh and tcsh family of shells (assuming we want to preserve reasonable highlighting compatibility), where << is allowed in expressions without double-parentheses delimiters. bash family shells like zsh and dash all seem to work like bash, so no problem there (touch wood). Folks using csh/tcsh ought to format their arithmetic expressions using a bit of spaces, but if they write 1<<32 then highlighting would break. So I'm thinking I'll add the extra symbols that are legal and use the BASH_CMD_ARITH state to help but continue to recognize (per existing behaviour) a number or a $ start (for csh/tcsh vars) as a non-HEREDOC.

     
    • Neil Hodgson

      Neil Hodgson - 2015-12-21

      There could be a property to choose csh/tcsh behaviour if needed.

       
      • Kein-Hong Man

        Kein-Hong Man - 2015-12-26

        Here is a patch. I have gone the lazy way and kept <<123 and <<$var for [t]csh shells which is existing behaviour (which no one has complained about so far.) <<= is modified a bit, allowed only in arithmetic delimiters since the operator does not appear to be in tcsh documentation. Apart from $ and = handling, all other legal symbols have now been whitelisted for HEREDOC delimiters.
        Attached LexBash.cxx and updated test cases.

         
  • Neil Hodgson

    Neil Hodgson - 2015-12-27
    • status: open-accepted --> open-fixed
     
  • Neil Hodgson

    Neil Hodgson - 2016-01-18
    • status: open-fixed --> 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