Use go_back_chunks() and go_forward_chunks() to adjust edittop and to
move up or down to the scrolled region before updating the rows there.
Now softwrap mode and non-softwrap mode will behave the same way when
we can scroll the top line of the screen partially off the screen,
which is forthcoming.

(Note that the top line of the screen can't be partially scrolled yet,
so we have to work around that for now.)

Not drawing a line on a row if we're on the top row and scrolled down,
or if we're on the bottom row and scrolled up, will only work properly
if the line on that row takes up only that row.  The latter might not
be the case in softwrap mode: if the line occupies multiple chunks and
begins on that row -- in that case none of the chunks would be drawn.

The old name made it sound as if it didn't apply in softwrap mode.  But
it does: in softwrap mode a line needs updating  when the mark is on.

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.

This addresses a followup of https://savannah.gnu.org/bugs/?50362

.
Reported-by: Mike Frysinger <vapier@gentoo.org>

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.

This fixes https://savannah.gnu.org/bugs/?50403

.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>

Of course 'row' needs to be initialized to zero for the softwrap case.

This addresses https://savannah.gnu.org/patch/?9215

.
Inspired-by: David Lawrence Ramsey <pooka109@gmail.com>

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>

Reflect the significant changes in painting and regex searching
in the copyright notices.

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.

The lines that come after an unpaired start have to know about this.

This fixes https://savannah.gnu.org/bugs/?50293.

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.

Scrolling works on rows, not on lines.  Accordingly, rename the nlines
variable to nrows.  And rows should be of the type int, not ssize_t.

There is no need to compute the line length: just avoid overstepping
the terminating NUL byte when being forced to advance the index.