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

And certainly don't return zero when the key wouldn't have been found,
because that would have meant jumping a word to the right.

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>

A third method does not exist.

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

Taking the terminating newline into account, and that there is
at least one digit per number.

For clarity and a tiny bit more speed.  Also rename some variables.

A filename might contain spaces, so we can't look for the numbers
(the second and third elements) starting from the head of the line
-- we have to start at the tail and work backward.

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

(I don't /see/ single-letter variables -- they are too small.)

It is irrelevant -- the line is discarded as soon as the data has been
extracted.

So they will not break a line in the positionlog file in two.

(Strangely, the reading in of such a log file already decodes
nulls back into newlines.)

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

Because changing anything to a null effectively means to truncate
the name.

This fixes https://savannah.gnu.org/bugs/?49868
and fixes https://savannah.gnu.org/bugs/?49874.

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.

Most full paths are needed only temporarily and will be freed within
milliseconds.  Only 'full_operating_dir' and 'backup_dir' continue to
exist for the whole current session.  Any partition, too, will soon be
unpartitioned, so the extra reallocation is just a waste of time.

It doesn't align anything -- any allocations are already aligned to
whatever multiple is required -- it just shrinks the allocated space.

And which normally is just some ten or twenty characters long, and
never gets wildly overallocated.

Nano would crash straight afterward if any of these asserts would fail,
so they don't add anything.  A few others are simply superfluous.

Also trim or improve a few comments.

That is: elide a second test from the most travelled path: a valid
character.  This adds a second call of mblen() when parse_mbchar()
is called on a terminating zero, but that should never happen.

The fsfromline() function is mostly used by the undo functions, which
are not present in the tiny version.  It is also used by the comment/
uncomment feature, but this feature cannot be enabled when --enable-tiny
is in effect.