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

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.

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.

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.

This disallows entering a verbatim ^J (0x0A) when typing text or
search terms, and disallows a verbatim ^@ (0x00) when typing a
filename.  Nano beeps when the disallowed code is attempted.

This addresses https://savannah.gnu.org/bugs/?49897.

In path names and file names, 0x0A means an embedded newline and
should be shown as ^J, but in anything related to the file's data,
0x0A is an encoded NUL and should be displayed as ^@.

So... switch mode at the two main entry points into the "file system"
(reading in a file, and writing out a file), and also when drawing the
titlebar.  Switch back to the default mode in the main loop.

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

Also, swap the logic around, to use less braces.

Which is possible because those keycodes are hard-bound to the relevant
functions.

In nano 2.7.1 and 2.7.2, pressing Shift+Ctrl+Arrow on a Linux console
would behave as if Shift wasn't held.  It got broken three months ago,
by commit 08cd197b, messing up the proper order of the checks.

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

On some systems, typing ^C apparently results in a KEY_CANCEL in
the input stream, which gets hard-bound to the do_cancel function.
But in the main menu there is no Cancel function.  So... in that
case, let it fall back to the plain old Ctrl-C code: 0x03.
Reported-by: Liam Gretton <liam.gretton@leicester.ac.uk>

There is no need for a counter, nor an old counter to compare it with.

The byte 0x0A means 0x00 *only* when it is found in nano's internal
representation of a file's data, not when it occurs in a file name.

This fixes the second part of https://savannah.gnu.org/bugs/?49867.

So that embedded control characters will be represented
instead of acted upon.

This fixes the first part of https://savannah.gnu.org/bugs/?49867.

Instead compute directly whether we're at a softwrapped part or not.

Convert digits() to take a ssize_t instead of an int, since it's
used on ssize_t line numbers.  And properly use the long modifier
when displaying a line number.

Also, conditionalize the digits() prototype.

This addresses https://savannah.gnu.org/bugs/?49803.

But do it correctly this time: don't switch it on when replacing.

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

Modern VTE-based terminals now produce codes for those keys and
no longer swallow them when nano is active.

This addresses https://savannah.gnu.org/bugs/?49746.

Only when doing replacements does the edit window need a refresh: for
every new spotlight.  So, do the update request in the latter routine.