When reporting a syntax without any color commands, show the line number
of the relevant 'syntax' command instead of the line number where the
emptiness is concluded, because the latter can be many lines later.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
The previous commit saves and restores filename and linenumber for
each single included file (after globbing), so it is now redundant
to do it for each 'include' command.
For each included file, save and restore file name and line number of
the including file, so that an error message about a faulty 'include'
command can indicate the location of this 'include'.
This fixes https://savannah.gnu.org/bugs/?56488.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
It's in a two-column format that fits on a single page, and uses the
more widely known Ctrl+X and Alt+X notations (instead of ^X and M-X).
The file is published on https://nano-editor.org/cheatsheet.html.
And generally improve the regex for coloring Perl variable names.
This fixes https://savannah.gnu.org/bugs/?56713.
With-help-from: Brand Huntsman <alpha@qzx.com>
Bug existed since the Perl syntax was introduced,
in version 1.2.2, commit 70047eef.
So that any message that is on the status bar after the search
will be a response to this search and not some leftover.
This fixes https://savannah.gnu.org/bugs/?56737.
Require that a comment starts at the start of a line or is preceded by
whitespace. This prevents most hash signs used for other purposes (and
what follows them) getting colored as comments.
This brings color to CakePHP template files, and to CUDA files.
This addresses https://bugs.debian.org/932192.
Requested-by: Jérôme Bardot <bardot.jerome@gmail.com>
When the user is typing a long text and --breaklonglines is in effect,
then any leading comment or quoting characters are automatically added
to each automatic new line.
This fulfills https://savannah.gnu.org/bugs/?56042.
Requested-by: Sébastien Desreux <seb@h-k.fr>
But don't blank it when using the word-deletion functions.
This addresses https://savannah.gnu.org/bugs/?56564.
Original-patch-by: Bill Hager <prog00@protonmail.com>
The check mistakenly prevented the user from copying a region that
ended at EOF. Removing the check also gives the user a way to clear
the cutbuffer (with M-A M-6 or ^6 M-6, for example).
This fixes https://savannah.gnu.org/bugs/?56563.
Reported-by: Liu Hao <lh_mouse@126.com>
Make display_string() report back (via a global variable) whether the
just converted string has room to spare within the allotted span, so
that draw_row() can avoid trying to clear the remainder when there is
nothing to clear.
This fixes https://savannah.gnu.org/bugs/?56562.
Bug existed since commit 699cacf7 from three days ago.
If the edit window consists of a single row, then the do_down() call
has already brought the desired line or chunk into view -- no attempt
should then be made to scroll the screen further.
This fixes https://savannah.gnu.org/bugs/?56553.
Bug existed since version 2.9.6, commit 0d9080a2.
It is a waste of time to first fully clear a row when right afterward
text will be written to it (for most of the row, on average). So...
just clear the part of the row after the written text. Curses has the
perfect function for this: clrtoeol().
The edit window has been fully cleared just before the list-drawing
loop has started, so there is no need to wipe anything. Only for the
highlighting bar all its characters need to be drawn with the correct
attributes.
Where the row needs to be filled with spaces with the attributes that
were set (title bar, prompt bar, and browser highlight), use printw().
But when the row needs to be actually cleared, use the much faster
clrtoeol().
This reduces the time needed to clear a full row with 95 percent.
Benno Schulenberg