nano-devel
[Top][All Lists]
Advanced

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

RFC: the coloring of unterminated comments (and such)


From: Benno Schulenberg
Subject: RFC: the coloring of unterminated comments (and such)
Date: Mon, 7 Mar 2022 11:35:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

Hello nano users,

Last week I noticed that other editors start coloring the text of a comment
as soon as the opening sequence of the comment has been typed (for example
/* in a C file).  But nano waits with coloring the text until also the
closing sequence has been typed (*/ in a C file).

Normally one doesn't notice this: one adds a comment in the middle of an
existing file, and there is some comment somewhere after the insertion
and the new opening sequence will match with the closing sequence of the
later comment, so the new text will be colored as a comment immediately.
But when typing a new file, or when typing at the end of an existing file,
one can see the temporary non-coloring.

Nano is rather alone in this.  Almost all other editors (vim, emacs, joe,
geany, gedit, fte, lpe, ne, and also dte, micro, and tilde), they all
color multiline comments as soon as there is an opening sequence, even
when there is no closing sequence in the rest of the file.  (The only
editor that I've found that behaves like nano is le.)

I am thinking of changing the way that nano colorizes multiline stuff
to match what other editors do, for three reasons:

1) It simplifies the painting code somewhat, thus making it faster.
2) Typing a multiline comment at the end of a file will behave the
   same as when typing it in the middle of a file.
3) It will be more obvious colorwise when there is an unterminated
   opening sequence near the end of the file.

What do you say?  Okay to change nano's painting behavior?

Benno

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

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