When the user answered No to a replacement prompt, skip the match
at the current position, so we don't stay stuck there.

Also, when replacing in the backward direction, or the match is
of length zero, skip the match at the current position, to not
get stuck.

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

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

This also fixes https://savannah.gnu.org/bugs/?50137,
and refixes https://savannah.gnu.org/bugs/?48635,
and fixes https://savannah.gnu.org/bugs/?50144.

That is: remove the special treatment of BOW anchors, and instead make
regexes match against the whole line instead of against an artificially
shortened one, because the latter method creates ghost matches: matches
at the starting point of the search that aren't really matches when seen
in the context of the whole line.

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

When the tail of a match falls outside of the marked region,
it is in fact not a match and should not be replaced.

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

When a replacement happens right at where the cursor sits, the position
of the cursor should not be adjusted, because the real cursor position
is between the current character and the preceding one: the place where
the cursor is shown is in fact right /after/ the insertion point.

This fixes https://savannah.gnu.org/bugs/?50134,
and fixes https://savannah.gnu.org/bugs/?50135.

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

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 use the 'startmatch' variable when the corresponding match is
not the start of anything but is the entire match by itself.

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>

The segmentation fault that this causes when both start and end match are
zero-length will be tackled later (https://savannah.gnu.org/bugs/?50056).

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

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

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>