The precalc_multicolorinfo() routine will assign a value to every
element for every line without looking at any current value, so
wiping the data first is a waste of time.
After having been allocated, the multidata will get computed
immediately, in precalc_multicolorinfo() and draw_row(), so
first setting each element to -1 is a small waste of time.
The initialization of -1 cannot possibly match with NOTHING or
WHOLELINE or the other available values.
(Also, put in a warning, as I don't think an onscreen line without
a multidata cache can occur at all.)
Backtracking from the first row is needed in case a start match was
added recently somewhere offscreen and the user jumped to the current
location (instead of scrolling) so that the CWOULDBE markings did not
reach the current lines.
Also, search for an end match only for the first screen row. For the
other rows, rely on the CENDAFTER, CWHOLELINE, and CWOULDBE values to
indicate whether there *is* an end match (the first two values) or not.
This saves considerable time when there is no end match in the large
remainder of a buffer: it will search in vain for the end match just
once, instead of for every row of the screen.
This fixes https://savannah.gnu.org/bugs/?59948,
and addresses https://savannah.gnu.org/bugs/?59945.
Bug existed since version 2.7.5, commit b3bcc8ee.
Like the other two fragments that advance over a zero-length match,
also this fragment should avoid the possibility of stepping beyond
the end of the line.
When a zero-length match is beyond the width of the screen, there
is no point in continuing evaluating the rule, so the check for
"offscreen to the right" needs to come first. The check for a
zero-width match needs to come second because otherwise we would
get stuck on such a match when it is offscreen to the left.
When the match of a coloring regex is beyond the width of the screen,
there is no point in continuing to evaluate the regex for the rest of
the line, because any other matches will be offscreen too.
This will save some time when there are several overlong lines.
A syntax has on average a dozen coloring rules, but on average maybe
three or four pieces of text (rough estimate) in a line get painted.
So, on average, it is cheaper to call wattron() and wattroff() only
when actually coloring a piece of text, instead of calling wattron()
before starting to evaluate each rule and wattroff() after finishing
its evaluation.
When reaching end-of-line after having found a zero-width end match,
nano should not continue at 'seek-an-end' but instead at 'step_two':
going on to seek a start match in the current line.
(There is no bug report, because I cannot figure out how to trigger
this issue and cause nano to misbehave. The problem was found while
reviewing the comments.)
Bug existed since commit 9a4a5454 from four years ago,
but the behavior was poorer before that commit.
When the filename, header-line, and magic regexes are first compiled
while reading in the rc files (to check their validity), REG_NOSUB is
used, but for some reason this wasn't done when each of these regexes
gets recompiled in order to be used. Fix this oversight. It shaves
some twenty percent off of each of these regexes' compiling time.
The combining characters (that are zero-width) start at U+0300.
After that it's pretty much chaos, width-wise.
The mbwidth() function is not called for control characters (whose
representation takes up two columns), as they are handled separately.
The calls of mbwidth() that *can* happen with a control character as
argument are only to determine whether the character is zero-width,
and then it doesn't matter whether the exact width is 1 or 2.
An invalid UTF-8 starter byte should not be represented in the same way
as a valid Unicode character.
This fixes https://savannah.gnu.org/bugs/?59832.
Bug existed since two weeks ago, since the mini-bar code was merged.
The first byte of a multi-byte UTF-8 sequence must be in the range
0xC2...0xFF. Any other byte cannot be a starter byte and can thus
immediately be treated as a single byte.
When the tail of the answer still fits exactly on the screen, the ">"
continuation character should not be shown -- also when the start of
the answer is "scrolled off" to the left.
This fixes https://savannah.gnu.org/bugs/?59816.
Bug existed in this form since version 4.0, commit 56181896.
When making small movements in the lower right corner, ncurses can
get confused about where the cursor actually is -- a double-width
character seems to throw its calculations off.
This addresses https://savannah.gnu.org/bugs/?59808.
Bug existed since version 5.4, commit 39705c60.
Benno Schulenberg