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

That is: don't try to look at open files when none are open yet.

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

This fixes https://savannah.gnu.org/bugs/?48751 reported by Andrew Ho.

This also fixes compilation when configured with --enable-tiny.

When using the default speller or the formatter, the placewewant is
remembered.  So it should be remembered too when the user specifies
a different speller.

(This behavior was inadvertently lost last year, in commit 82d737ee.)

If this breaks your build, please send report or instructions or patch.

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

Instead be more specific and say that the directory is not writable.

This fixes http://savannah.gnu.org/bugs/?48698

.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>

It is quicker to do a handful of superfluous compares at the end of
each line than it is to compute and keep track of and compare the
remaining line length the whole time.

The typical line is some sixty characters long, the typical search
string ten characters -- with a shorter search string the speedup is
even higher: some fifteen percent.  Only when the string is longer
than half the average line length does searching become slower with
this new method.

All this for a UTF-8 locale.  For a C locale it makes no difference.

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.