[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Benno Schulenberg
Subject: Re: [Help-nano] Bash syntax highlighting: Quoted text in comments
Date: Mon, 19 Feb 2018 18:21:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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.

>> (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.

> 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.

> 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).


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]