Add the new functions current_is_above_screen() (which doesn't account
for softwrapped chunks yet, but will when we can scroll edittop partially
off the screen, which is forthcoming), current_is_below_screen() (which
determines whether current[current_x] is past the softwrapped chunk at
the bottom of the screen), and current_is_offscreen() (the union of the
previous two functions).
edit_redraw() and edit_refresh() now use current_is_offscreen() to check
whether they should adjust the viewport, and adjust_viewport() now uses
current_is_above_screen() to determine whether current is on or below
the screen in FLOWING mode.
Add the new function less_than_a_screenful() to accomplish this.
It uses go_back_chunks() to count the number of softwrapped chunks
between the end point and the starting point of the paste.
Now softwrap mode and non-softwrap mode behave the same way when
uncutting fewer than editwinrows rows of text. Accordingly, remove
the call to ensure_line_is_visible(), as it no longer applies.
These functions, go_back_chunks() and go_forward_chunks(), take a number
of softwrapped chunks (screen rows) to move, a pointer to a buffer, and
a location (specifically, a starting column of a softwrapped chunk). If
they move successfully, they will update the buffer pointer and location
to point to the beginning of the softwrapped chunk they moved to.
Since non-softwrap mode is effectively just a subset of softwrap mode
in which every line takes up one chunk, these functions also work in
non-softwrap mode. In this case, their starting column will always be
zero, as it would be in softwrap mode on a line that takes up one chunk.
Nothing uses these functions yet, but that is forthcoming.
Instead of redetermining the entire span of the converted string,
simply move one character left, and then bite it off to make place
for the trailing $.
If the last two columns of a row would be taken up by a double-width
character (and the line is longer than that), don't print it, because
it wouldn't leave any room for the $ character.
This fixes https://savannah.gnu.org/bugs/?50491.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Running strlenpt() on a string that takes up more than 80 columns
(the width of an average terminal) takes /more/ time than simply
converting an extra character (the one that will be overwritten
by the "$" at the edge of the terminal). So... just convert one
more character than necessary when the line is overlong. In the
most common case, however, the line will fit fully onscreen, and
we save a whole call of strlenpt().
Since we only need span columns of the string, stop scanning the string
as soon as we have that many columns, instead of scanning the string all
the way to the end. This speeds up the conversion of very long lines.
In softwrap mode, the entire line is onscreen, so the word is never
partially offscreen, so we always have enough columns to show it.
This fixes https://savannah.gnu.org/bugs/?50389.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Instead of allocating enough space to convert the entire passed string,
just allocate space for converting the part that will be converted --
that is: starting from start_index. This still allocates far too much
(if the passed string is very long and its tail part won't fit on the
screen), but it's better than before.
Cap the number of pauses when displaying ALERT messages, to avoid
making the user wait for ages when tens or hundreds of files were
specified on the command line.
This fixes https://savannah.gnu.org/bugs/?50362.
Reported-by: Mike Frysinger <vapier@gentoo.org>
When in softwrap mode, no "$" continuation characters are displayed,
so the code that reserves space for them should be skipped then.
This fixes https://savannah.gnu.org/bugs/?50335.
When coloring a line, look only at the multidata of the preceding
line, and based on that determine what to seek in the current line.
This fixes https://savannah.gnu.org/bugs/?50292.
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.
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>
During precalculation and in step_two, we begin looking for an end
match only after the full start match, not merely one byte beyond
its starting point. So do that too when searching backward for an
unpaired start match.
Also, index can never be zero here, because if the match was of length
zero, this piece of code will have been skipped by the preceding goto.
So we can always use REG_NOTBOL here.
(That goto is wrong, by the way: https://savannah.gnu.org/bugs/?50078,
but that will follow later.)
If the given line is out of range of editwinrows, we don't display it
at all, so we obviously don't display more than one line of it. Thus,
the return value in this case should be zero, not one.
