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

Mentioning "GNU nano" instead of "This program" and referring to the
website instead of to a postal address.

And remove a superfluous call.

The prompt has already been trimmed in do_prompt() to fit into the
available space.

Leave the optimization of actual screen writes to ncurses.

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

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

The $ sign looks too much like an S, and it "obscures" the answer by
being so "massive".  The < and > signs are lighter and work better.

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

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

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

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

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

That is a task for the key-getting 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.

Color-pair numbers and attributes can be OR'd together -- do so,
to save an attron() call whenever the hilite is on.

When we get a ^J as verbatim input, it is not possible to include it
into the file buffer or the prompt answer, because this would mean
adding an encoded null to the buffer or answer, and that is not what
the user intended.  One option would have been to simply ignore a ^J
in verbatim input.  But the choice has been made to act the same way
as when the ^J (0x0A) is found in the file data: start a new line.

That is the same response as to the Enter key, yes -- but the code
for the Enter key is ^M (0x0D), not ^J.  So, to be more precise,
rename the relevant variable from 'got_enter' to 'got_newline'.

Don't make it the responsibility of the executed functions to restore
the list of shortcuts of the edit window.  Just detect whether another
menu was displayed, and if so, redisplay the main menu.

This restores things to the way they were before commit 36ec76a5.
Apparently all those refreshes are needed in some cases after all.

Commit 36ec76a5 made the wrong change: after a tab that did not list any
file names on the screen, a refresh /is/ needed, because a previous tab
might have listed things on the screen.  But at the end of the prompt,
it is not necessary to refresh the edit window if things were listed,
because the window will be refreshed anyway after reading in a file.

This is a remnant from 2001, when things were different.  Now, there
is no need to refresh the edit window when tabbing produced no list.
When it did produce a list, it is cleared off later.