The 'color' commands of a syntax definition should not be allowed to
be interspersed with other, non-syntax commands.
This fixes https://savannah.gnu.org/bugs/?56498.
Bug existed since before version 2.6.0.
As 'extendsyntax' commands are no longer interpreted immediately when
the rcfiles are read, there is no need to set 'opensyntax' to FALSE
after interpreting such a command -- for a single syntax they are all
interpreted in a row.
An included file can contain multiple syntaxes. If reading would stop
as soon as a command different from 'syntax' and 'header' and 'magic'
is found, any later syntaxes would not be seen. So each nanorc file
needs to be fully scanned -- it's just the interpretation of all the
color commands that we want to delay until the syntax gets actually
used.
This fixes https://savannah.gnu.org/bugs/?56478.
Bug existed since commit cba9d8d0 from a month ago.
Instead of calling in twenty places parse_mbchar(pointer, NULL, NULL),
use a simpler and faster char_length(pointer). This saves pushing two
unneeded parameters onto the stack, avoids two needless ifs, and elides
an intermediate variable.
Its main purpose will follow in a later commit: to speed up searching.
When a syntax gets parsed, store the compiled color regexes right away,
instead of compiling them a second time in color_update().
This addresses https://savannah.gnu.org/bugs/?56432.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The /etc/nanorc file should not define any syntax directly (and
preferably not include any either, to not slow startup down with
syntaxes the user is never going to use), and if the ~/.nanorc file
defines a syntax directly, there is no need to use 'extendsyntax':
the command can be added to the syntax itself -- it would be better
even: it keeps things together.
Extending a syntax will be rather rare, so the amount of memory it
takes up will be minimal. It's not worth the trouble to free this
memory -- it only takes time. Plus: we don't bother to free the
memory of a syntax that gets fully redefined either.
When an included file has just been fully parsed, 'lastcolor' is still
pointing at the last color regex that was added to the list -- no need
to refind the end of this list.
When parsing an included syntax file, stop reading when a command other
than 'syntax', 'header' or 'magic' is encountered. The syntax file is
fully parsed the first time that a file needs it. Each 'extendsyntax'
command is stored for unloaded syntaxes and applied after the syntax
is loaded.
Closing a buffer does not unload the syntax, even if no longer used by
another buffer.
This addresses https://savannah.gnu.org/bugs/?54928.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
This is needed to implement the demand loading of syntax files, as any
errors that these files may contain would otherwise overwrite things on
the screen and the messages wouldn't be on the terminal when nano exits.
It also allows nano to start up on a Linux console when there are errors.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
For relatively inexperienced users (as most users of nano probably are)
it is far better that nano produces POSIX text files by default, where
each line ends with a newline character. This means that these files
will "print" properly (not gluing the next prompt at the end of the
last line), tools will see and process each line of them, and, while
editing, adding text at the end is easier.
This addresses https://savannah.gnu.org/bugs/?55997.
Reported-by: Ralph Corderoy <ralph@inputplus.co.uk>
The reading order must be predictable, otherwise things might get
colored differently from system to system.
This fixes https://savannah.gnu.org/bugs/?56012.
Otherwise the user could do something like
^R^X sed -i 's/a/surprise!/g' name-of-current-file <Enter>
and the file being viewed would be modified anyway.
Option -J (--guidestripe) takes a column number as argument and then
shows a vertical, colored bar over the entire height of the buffer,
to aid the user in regulating the width of the text when the terminal
is wider than this desired width.
This fulfills https://bugs.debian.org/916392.
Requested-by: Arturo Borrero González <arturo@debian.org>
And fulfills https://savannah.gnu.org/bugs/?55315.
Requested-by: Bryan Christ <bryan.christ@gmail.com>
Benno Schulenberg