Now that mbstrncasecmp() does the right thing, there is no need any
more to verify that only a valid multibyte sequence was matched.

(See https://savannah.gnu.org/bugs/?45579 for a test case.)

Also, this will make it possible to search for invalid sequences.

(Currently it isn't possible to enter a search string with invalid
characters, but... a user might edit the search history file.  And
if pasting at the prompt is implemented, it will be trivial to enter
invalid sequences if you have a file that contains them.)

Persisting might lead to count 'n' reaching zero, which would mean that
the needle has matched, which is wrong when one of the strings contains
an invalid or incomplete multibyte sequence.

That is: don't run towlower() on the two differing bytes when having
reached the end of one of the strings.

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

In the bargain, don't do the conversion to lowercase twice.

Furthermore, persist when encountering invalid byte sequences --
until finding bytes that differ.

The needle is never part of the hay -- it is always a separate string.

(And even if needle and haystack were identical, the routine works fine,
the case does not need special treatment.)

This fixes https://savannah.gnu.org/bugs/?48660 doubly, in case there
are other ways in which 'spell' sees words differently from 'nano'.

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

Straightforward code is more important than the tiniest possible binary.

Also adjust some comments and rename a variable.

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

(It may have been necessary in the past; there is no need for it now.)

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

When doing an <Up> on the top line, or a <Down> on the bottom line of
the edit window, the affected lines have already been redrawn by the
scrolling code, so there is no need to do that again.

(However, that does not prevent the second line (or the last-but-one
line) from being redrawn unnecessarily when using the M-- (or M-+)
command elsewhere on the screen and /that/ line is horizontally
scrolled.  But we'll let that pass for now.)

For horizontal scrolling, it is not the /desired/ column position that
is relevant for determining whether a line needs to be redrawn after a
cursor movement, but the /actual/ column positions before and after.

This fixes https://savannah.gnu.org/bugs/?48627,
and fixes https://savannah.gnu.org/bugs/?48629.

Having two unneeded parameters in the tiny version is acceptable --
the code gets so much more readable.

This addresses https://bugs.debian.org/831636 reported by Christoph Biedl.

Leave the rest of any escape sequence to be processed normally, which
should be possible because those characters are all in ASCII range.

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

These codes are the basic codes that get assigned for the movement keys
in the list of shortcuts -- they don't need any translation.

That is a task for the key-getting routine.

Again, just for preapring an easier return from the parsing routine.

There is no need to specially flag a function key or editing key --
the keycode is indication enough in itself: outside of byte range.

Saving roughly twenty microseconds at startup.

Also, when a key string does not denote a Ctrl nor Meta nor Function key,
there is no point in assigning a keycode, because plain characters cannot
be used as a function shortcut.

The keycode is not a sequence; it is a single integer value.

And instead of using two key types, just use a bool to indicate whether
a keystroke involves Meta.

A keycode is either already in byte range (so there is nothing to do)
or it is not and it shouldn't be (so there is nothing to do either).

After initialization, the type of a key is never used nor needed
(other than for meta keys).

Accept the "Esc [ 1 n ~" and "Esc [ 2 n ~" sequences only when they
end with the "~" character, not with any character.