(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'.

Also adjust a few comments.

In order to determine the correct multidata for a line that doesn't
have such data yet, the whole line must be examined, not just the
part that fits within the screen width.

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

A tag begins not merely with a "<" but it must be followed by an
ASCII alphabetic character or one of "/", "!" and "?".

Further, color all the valid attribute names in red.

That is: only extend the current Del or Backspace undo item when the
cursor is still (or again) at the same spot.

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

If the system on which nano is configured does not have the 'makeinfo'
program installed, the prebuilt and packaged nano.info and nano.html
should nevertheless be installed.

Also, the TEXINFOS primary has built-in rules for generating HTML files
from the texinfo sources, so an explicit rule is not needed.

This indirectly addresses https://savannah.gnu.org/bugs/?49969.

(This should have been updated when the Changelogs were renamed.)

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

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

Instead of setting openfile->current_y (and wrongly so), just call
reset_cursor() to recompute current_y and place the cursor on that
line (if it is not offscreen).

The search routine begins searching right after the cursor and behaves
as if the line starts there, which means that a beginning-of-word anchor
(\< or \b) will match there also when in fact the cursor is sitting in
the middle of a word.  To prevent finding a false match, verify that
for a regex that starts with a BOW anchor the found match is actually
the start of a word.

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