#1347 Wrong syntax highlighting with Shell

Bug
closed-duplicate
SciTE (627)
5
2013-11-19
2012-04-06
Sworddragon
No

I'm using SciTE 3.0.4 and subshells which are quoted are looking strange. In the attachment is an example screenshot which shows in the first block how the syntax highlighting is looking normally. The second block is without quoting and the third block is quoting but these blocks aren't using the normal syntax highlighting for the subshell.

Discussion

  • Kein-Hong Man

    Kein-Hong Man - 2012-04-06

    This is a duplicate of SF ticket #1515556, also discussed on ticket #3512208. AFAIK nobody is currently in the process of implementing highlighting of nested delimiter pairs.

     
  • Neil Hodgson

    Neil Hodgson - 2012-04-06
    • assigned_to: nobody --> nyamatongwe
    • status: open --> open-duplicate
     
  • Kein-Hong Man

    Kein-Hong Man - 2012-04-10

    I'm looking into implementing basic nesting capabilities. Say, limit nesting to 8 (enough for all sane people) and ignoring backslash issues for now (interesting to know who'd be hero enough to use backslashes in the >=2 nesting level of a string).

     
  • Sworddragon

    Sworddragon - 2012-04-10

    > I'm looking into implementing basic nesting capabilities. Say, limit
    > nesting to 8

    I think it should be configureable. I have never needed a nesting level of more than 1 but who knows if some people still need it for some very special things.

     
  • Kein-Hong Man

    Kein-Hong Man - 2012-04-10

    8 levels of nesting should be enough for everyone. :-)

    Kidding aside, many of the complex lexers are full of artificial limitations and corner cases that breaks highlighting. All sane programmers would never encounter them. I'll leave the perfection part to other contributors.

    Anyway, from what I can determine, the primary nesting delimiter is $(command) and `command`. For example, "string" by themselves cannot nest, you must escape the extra delimiters. You need a level of say $(command) nesting separating two "string" levels. Hence, 8 levels must involve between 4 to 8 nesting levels of $(command) or `command`. Yea, I sure would like the person who write real code like that to file a bug report...

     
  • Kein-Hong Man

    Kein-Hong Man - 2012-04-12

    The following works on a recent Cygwin bash:

    echo $(echo $(echo $(echo $(date))))
    echo `echo \`echo \\\`echo \\\\\\\`date\\\\\\\` \\\` \` `

    Implementing nested $(command) is reasonable. However, `command` need to have backticks escaped. Unfortunately, when nesting `command`, the backslash escapes need to exponentially increase to make up for escape handling. I'm leaning to ignoring such escaped backticks for a first implementation. Let 'em file a bug report... :-)

     
  • Neil Hodgson

    Neil Hodgson - 2012-10-21
    • status: open-duplicate --> closed-duplicate
     
  • Sworddragon

    Sworddragon - 2013-07-20

    The 2 previous reports are marked as fixed but on SciTE 3.3.4 I'm still seeing a result close to the initial screenshot in the startpost.

     
  • Kein-Hong Man

    Kein-Hong Man - 2013-07-20

    And which part of that highlighting is wrong? Point it out precisely...

     
  • Sworddragon

    Sworddragon - 2013-07-20

    It is the same thing that I have described in the startpost: Shouldn't the nesting of block 2 and block 3 look like block 1?

     
  • Cousteau

    Cousteau - 2013-11-18

    The $(...) command substitution seems to be considered now: the quotes inside of it are not interpreted as string end. The only issue is that stuff within $(...) is highlighted as part of the string rather than code. Personally I'd prefer it to be highlighted as regular code, but at least Scintilla seems to be correctly detecting that those quotes don't mark the end of the (outer) string.

    In other words: the bug seems to be fixed but the visible changes are not as big as you might have expected.

     
  • Kein-Hong Man

    Kein-Hong Man - 2013-11-18

    This is a closed ticket. Open a new one if you want, with proper details. Scintilla string style is different from gvim, so no specific delimiter colours. Using string semantics, nested strings can be lexed cleanly. Also I can't find any FLOSS with bash scripts that use $(). I won't work on this, maybe others might, if they feel it is important to them.

     
  • Cousteau

    Cousteau - 2013-11-19

    I just commented that to explain that the bug was fixed and that the behavior is right, even if the change wasn't visually evident.  I think the current solution is OK.

    Regarding shell scripts using $(), «grep '\$(' -IR /usr/bin | less» threw quite a few results (some of them even with nested $($()), such as xdg-open: «file="$($printf "$(echo "$file" | sed -e 's@%\([a-f0-9A-F]\{2\}\)@\\x\1@g')")"»).  Geany highlights it correctly; there's no sophisticated syntax highlighting within the $(...) but at least the highlighting doesn't get messed up as it did before.

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks