This code:
# some comment\ some more comment NOT!
... highlights as if the second line was comment, but zsh at least treats it as code.
Highlighting is done by the editing component which comes from the [Scintilla](scintilla.org) project. We ask that Scintilla lexer bugs be reported directly to that project so there is not another communication step if there are questions. As Geany uses a slightly older version of Scintilla it might be worth testing it with the latest release of the reference editor Scite first.
Please post a link to the Scintilla report here.
Sorry, how do I post a link? Did you just do that with your "added the scintilla label" post above? If so, then am I done?
@RayAndrews56, @elextr is hoping you will open a bug on [the Scintilla bug tracker](https://sourceforge.net/p/scintilla/bugs/) (there might already be one for this, worth searching first), the project where the actual bug you're experiencing would come from. If you're willing to do that, he's asking for you to post a link to your bug report (or any existing one(s)) on their bug tracker so we can reference it here on your Github Issue.
That said, assuming the lexer is to conform to [POSIX Shell standards](https://pubs.opengroup.org/onlinepubs/007904875/utilities/xcu_chap02.html) ([`zsh` uses the normal shell lexer in Geany](https://github.com/geany/geany/blob/d9f8cdbad58d09f0c18ca8acccb49209263018f0...)), it might not be an actual bug, specifically this:
A backslash that is not quoted shall preserve the literal value of the following character, with the exception of a <newline>. If a <newline> follows the backslash, the shell shall interpret this as line continuation. The backslash and <newline>s shall be removed before splitting the input into tokens. Since the escaped <newline> is removed entirely from the input and is not replaced by any white space, it cannot serve as a token separator.
Ok I reported it to Scintilla but I have no idea how to link it back to here. Sorry, I'm not very familiar with any of this. Your quote would seem to suggest that zsh has it wrong tho.
Link: https://sourceforge.net/p/scintilla/bugs/2226/
I'm not saying Zsh has it "wrong" per se, just that it seems to be the correct behaviour for POSIX shells, and that in Geany, `*.zsh` files use the regular [Shell filetype](https://github.com/geany/geany/blob/d9f8cdbad58d09f0c18ca8acccb49209263018f0...).
Well, bash is "wrong" too then
```bash #comment\ echo foo ```
echos foo.
But reading the [POSIX spec](https://pubs.opengroup.org/onlinepubs/007904875/utilities/xcu_chap02.html) suggests the `<newline>` should be removed before token recognition which is when the comment is recognised, so the highlighting is correct for POSIX shells. `</language lawyering>`
Since there is only one highlighter for all "shellish" things it won't match all of their deviant behaviours, so I guess its up to the maintainer of the lexer in Scintilla which it matches, POSIX or bash (as most popular) or what.
Is there a posix compliant 'shell' we can try? As above, bash and sh flunk out the same way. If there's no other shell that passes this test then they should change it.
And if you think about it a comment is a comment ... there is no active code in a comment line so parsing the backslash is dumb. You might have commented out some line of code that has a trailing backslash and you want it *inactive* not killing the next line of code too by trying to make it part of the comment. Dumb!
If you commented out a line of code that ended in a backslash it would be a continuation onto the next line, so unless half a line makes sense you would actually want the comment to apply to both, so the _shells_ are dumb.
Of course if _I_ was the Scintilla maintainer I would just say "Don't do that, its silly" :grin:
It's debatable and I think you can make a case either way. If you think of it as commenting out a logical line, then of course the wrapped logical line should be commented, but if you think of it as a physical line then only the physical line should be commented. Consider this: ``` [ "$int" = "$highlight" ] && zcurses attr "$win" +reverse\ || zcurses attr "$win" -reverse ``` I break the line for pleasing visuals. Ah! But I have an improvement:
``` # Edit: use 'var' not 'int': #[ "$int" = "$highlight" ] && zcurses attr "$win" +reverse\ [ "$var" = "$highlight" ] && zcurses attr "$win" +reverse\ || zcurses attr "$win" -reverse ``` ... now, just hacking along like we do, I'm saving the original and then editing the first line and I'm not expecting that this is going to turn the whole code into a comment, am I?
You can argue it either way, but the FACT is that zsh, bash and sh (at least) all have the 'physical line' point of view, so the highlighting should follow the facts not the theory.
Seems weird that this wouldn't have been noticed before tho, so maybe Scintilla doesn't care.
A certain Neil Hodgson seems to have looked at this but I have no idea what he's saying:
- Description has changed:
Diff:
~~~~
--- old +++ new @@ -1,4 +1,4 @@ -~~~ +~~~zsh
function test2 {
~~~~
- **Comment**:
A simpler example is: ~~~bash # comment \ echo "not a comment" ~~~ which displays `not a comment` when run with zsh or bash.
There are separate elements in the zsh documentation for continuation and comments with no information on priority.
http://zsh.sourceforge.net/Doc/Release/Shell-Grammar.html#Quoting :
A character may be quoted (that is, made to stand for itself) by preceding it with a ‘\’. ‘\’ followed by a newline is ignored.
http://zsh.sourceforge.net/Doc/Release/Shell-Grammar.html#Comments :
a word beginning with the third character of the histchars parameter (‘#’ by default) causes that word and all the following characters up to a newline to be ignored.
---
** [bugs:#2226] zsh 5.8 on Debian Stretch.**
**Status:** open-accepted **Group:** Bug **Labels:** lexilla lexer bash zsh **Created:** Wed Dec 30, 2020 12:59 AM UTC by Ray Andrews **Last Updated:** Wed Dec 30, 2020 09:38 PM UTC **Owner:** nobody
~~~zsh
function test2 { # this is a comment\ is this a comment continued on the next line? } ~~~
zsh treats the second line as code, but it highlights as a continuation of the comment.
This is easier to read:
https://sourceforge.net/p/scintilla/bugs/2226/
Please don't copy everything from the Scintilla bug to here, @codebrainz posted a link to it above.
Pardon, I don't know the ropes.
I just wanted to add that as far as I know this is standard behavior. It is consistent in bash, dash (the closest thing to a POSIX shell I've seen), zsh, and even the heavily nonstandard csh.
It seems to be quite extended too, to the point that some scripts rely on that behavior. For example, in Tcl (where the \ _does_ continue the comment) [this kind of comment is often used to trick the shell and run tclsh](https://wiki.tcl-lang.org/page/Tcl+Style+Guide#e36409f3b7db7eef854e2fe30892a...).
So the good news is that this doesn't need to be handled specially for zsh only, but for shell scripts in general, so once Scintilla fixes the bug Geany won't need to do anything weird.
Well, the shell lexer maintainer in Scintilla noted they were busy and inviting submissions to fix it, so its up to "somebody" to do it.
github-comments@lists.geany.org