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.)

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

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

A search should start at the place of the cursor, not one step beyond,
so that the non-word boundary between the current character and the next
will be found.  Starting one step beyond the current character, as was
done until now, would find the non-word boundary between the next and
the overnext character as the first one.

And return a better value, so that less calculation is needed.

(Ignore the indentation for the moment.)

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.

And columns from indexes -- columns are places on the screen, while
indexes point to characters in a line in the current buffer.

(The mistake becomes visible when you go to the end of a very long line
of double-width characters: the $ will be shown on the right edge, even
though you're already at line's end.)

This reverts commit 16a7fd4b from yesterday.

What is the point of parsing a number when you're not interested in
the result?  All callers of parse_num() pass a container for it.

This addresses part of https://savannah.gnu.org/patch/?9216

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

When there is no end match after a start, it is pointless to look
for any more starts because also they will not have any end match,
so nothing will get painted -- just cut the loop short.

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

The tiny version can do regex searches nowadays, so the user might use
the \< and \> anchors in their regexes.

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

The renamed variable 'index' is not the start of a match (as some comment
mistakenly said), but from where in the line we start looking for a next
match.

Also, use one more goto to allow unindenting a big piece of code, and
shortcircuit two while loops for two more small unindents.

The setting of current_y in copy_from_filestruct() also appears to be
a holdover from the days of a more-common STATIONARY scrolling mode.

do_cut_text() uses the above function when copying text (uncutting
text again right after cutting it).  Since the text is effectively
the same afterward, current_y doesn't need to change.

do_uncut_text(), however, does need current_y up to date in one case:
when uncutting a full screen or less' worth of lines, focusing will be
FALSE, and it uses edit_refresh(), so it will use STATIONARY scrolling
mode then.  Take a cue from do_insertfile() and call reset_cursor() to
get an updated current_y.

(Note that the check for a full screen or less' worth of lines uses
incorrect values when in softwrap mode, but that's a separate problem.)

undo_cut(), do_redo(), and backup_lines() do not need set current_y
because they all result in edit_refresh() with focusing = TRUE, so
they do a CENTERING scroll which does not need current_y.

At first paintlen was computed as a column span, and then converted
to a character count...  Confusing.

The top_x variable has already been forced to become equal to from_x
if it was before it.  So start_col will be at least zero.

It is the misuse of "x_" to mean a column position on screen, and the
misuse of "_col" to mean a character position in a string that causes
this confusion.

All these different "start"s and "end"s are confusing.  Use instead
'from_x and 'till_x' to remember which part of the current line is
visible now on screen and is thus represented in 'converted'.