RFC: the coloring of unterminated comments (and such)
Benno Schulenberg <[email protected]>
| Newsgroups | gmane.editors.nano.devel |
|---|---|
| Message-ID | <[email protected]> |
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
OpenPGP_signature
(application/pgp-signature, 840 B) - not displayed