When replacements are made, nothing needs to be reset any more
(it was done insufficiently anyway). Just make sure the screen
is refreshed when all is done -- this may be superfluous when
doing interactive replacements, but not when replacing all.
When painting a line, the multidata of the line /before/ it is valid
in most cases: it was determined just a moment ago. And it tells us
all we need to know: whether there is an unpaired start match before
the current line or not.
The only exception is when painting the first line of the screen:
the multidata of the line before it might be stale. So for the
first screen line we will always have to do some backtracking.
But that is left for later.
This fixes https://savannah.gnu.org/bugs/?50121.
Just assign the 'CNONE' value upfront, instead of figuring out
at the end of the line whether anything has been assigned yet.
Also, the old logic would leave unmarked a line that contains a
start match without any terminating end match. Not serious, but
not right.
Don't blithely overshoot the end of a line when both start regex and
end regex match an empty string. Overshooting would let the matching
run on into uncharted country and thus ultimately cause a segfault.
This fixes https://savannah.gnu.org/bugs/?50056.
Reported-by: Elia Geretto <elia.f.geretto@gmail.com>
Also, compose the coloring attributes during initialization
instead of every time when painting something.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Precalculation of the multiline color data can be cut short when the
user is impatient and starts typing. But this would drop the first
byte of whatever was typed -- not nice when it was just plain text,
but surprising and worse when the first keystroke was a command.
This fixes https://savannah.gnu.org/bugs/?48388.
When for a multiline syntax-coloring rule the starting regex matches at
the exact same spot as the ending regex, do a second round of resets, so
that reevaluation starts further back and gets a few more things right.
This mildly fixes https://savannah.gnu.org/bugs/?47420.
If during startup there are multiple error messages, currently only the
last one remains and can be read. To improve on that, introduce a short
pause between error messages -- even if it's not enough to read them all,
at least the user will be aware that there are multiple ones.
This also causes a few error messages to beep that currently don't beep,
such as when a file is unwritable.
For a little contrast with the function edit_refresh() -- it's
annoying that when you search for the latter you get to see all
the settings of the flag too.
using it when it's available (which it is on OS X systems).
This completes the fix for Savannah bug #47325.
Patch by Thomas Rosenau.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5759 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
comes first, so that a search can stop at the first match instead of always
having to run through the entire list.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5716 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of the first syntax that matches a certain magic string
(forgotten in the previous commit).
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5705 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
name given on the command line, not from the name of the target file.
This fixes Savannah bug #47307.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5703 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to file extensions, but also to header lines and magic strings.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5690 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Benno Schulenberg