Re: [Help-nano] Bash syntax highlighting: Quoted text in comments

[Michael Siegel]

Am 19.02.2018 um 18:21 schrieb Benno Schulenberg:
> 
> Op 19-02-18 om 17:09 schreef Michael Siegel:
>> Am 18.02.2018 um 11:11 schrieb Benno Schulenberg:
>>> But... maybe a point could be made that quotes in comments are more
>>> common than space plus hash in strings?  What do you think?  Do you
>>> have a large set of scripts that you can grep?
>>
>> Unfortunately, I don't. And I would say that whatever such statistics
>> may show, potentially having the highlighting of your actual code
>> screwed up is definitely worse than having strings in comments
>> highlighted in a different color, which is, after all, kind of trivial.
> 
> True.  With the current shell syntax rules, in the following example
> it is just 'somefile;' that will be colored as if it were a comment:
> 
>   grep "such #so" somefile;
> 
> But if we swap the coloring of Comments and Strings, then the whole
> '#so" somefile;' would be colored as a comment, which looks ugly and
> makes the command hard to read.

Ok, I've tried that and seen the difference.

>>> (I now see that the order of comment and string highlighting was
>>> changed in the beginning of 2014, from nano-2.3.2 onwards.  Maybe
>>> that swap should be turned back?)
>>
>> Well, I haven't noticed any differences between versions 2.2.6 (which
>> I'm still using on one of my systems) and 2.7.4 so far, as far as
>> highlighting Bash scripts goes.
> 
> If you try the above example on both systems, you should be able to
> see the difference.

Well, the order of the regexes for coloring comments and quoted strings
in sh.nanorc is the same across both versions on my systems (And I'm
pretty sure I've never touched that file.). So, as long as you don't
swap that around, there's no difference between 2.2.6 and 2.7.4 in
highlighting your example.

>> So, are there any chances that nano will gain the ability to fully parse
>> scripts for highlighting in the near future?
> 
> No, no chance.  Nano is a small editor, fully parsing all the files
> for which it provides syntax coloring is not within its scope.

I see. But then, the code parsing wouldn't necessarily have to be
handled by nano itself, would it? I mean, wouldn't it be possible to
equip nano with the ability to make use of an external parser? That
would surley slow things down, but maybe not so much after some
optimization.

>> PS: Another small thing I noticed: Why would you bind the copy-to-buffer
>> action to M-^/M-6 when cut to buffer is ^K/F9 and paste is ^U/F10? Seems
>> inconsistent to me.
> This feature (copy-to-cutbuffer) was added in April 2006.  It is
> a feature that Pico doesn't have.  There were no Ctrl+letter keys
> left to assign it to, nor any function keys.  So, as it has something
> to do with marked text, I suppose the idea was that a key should be
> chosen that is related to toggling the mark (Ctrl+^ or Ctrl+6).

I see. Well, you can rebind it anyway. So, no big deal.


Best,

Michael