CONST_UPDATE is only relevant when in the main menu, not when in the
browser.  So, check for that condition, instead of saving, changing,
and then restoring the setting.

CONST_UPDATE does not need to influence the delay for blanking the
statusbar; it is enough when it simply prevents it.

When in the browser, typing keys that produce an unknown escape sequence
should not switch on the cursor.

Take the side effect of a 'statusbar' call -- setting suppress_cursorpos
to TRUE -- into account.  This effect was overlooked by commit 9d6d5b67.

Cancelling a search should restore waiting mode for the keyboard,
just like at the other exit points of the search routine.

And when the input routine has read in multiple keystrokes, it
should not blindly switch back to waiting mode, but only when
that mode was on before.

This fixes the second half of https://savannah.gnu.org/bugs/?47438.

When the terminal is very narrow, there is little point in showing only
part of the version string -- and chewing off one or two digits from the
version number might even give someone a wrong idea.  The user is better
served with always showing the full filename, as long as it fits in the
available screen width.

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

For some reason the keyboard code seems to assume that all integers
waiting in the keybuffer form a single sequence.  But this isn't the
case: when there is an escape (0x1b) among them, then that is where
a new sequence starts.  So, prevent the input code from considering
an escape after a non-escape as part of the current sequence.

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

It is misleading to say "Unknown Command" when there is no way to rebind
the relevant key stroke do anything useful.

For a little contrast with the function edit_refresh() -- it's
annoying that when you search for the latter you get to see all
the settings of the flag too.

The function edit_update() is called by edit_refresh() itself, so it is
silly that the first sets 'edit_refresh_needed' to TRUE.  This setting
is needed only in a few cases -- in the others it's not needed because
the screen does not need to be refreshed (it was just about positioning
the cursor), or 'edit_refresh_needed' has already been set by a call to
goto_line_posx().  So, just set the flag in the five places that need it
and spare the other four calls.

If nano has less than four columns available, it will die,
so there will always be room for at least four characters.

Also, don't force a full refresh of the edit window simply because the
current line needs to be horizontally scrolled.  And further, when the
adjustment of edittop has determined that a full refresh is needed,
get out and don't bother scrolling some lines first.

The old_current line needs to be redrawn only if it differs from current,
and if it wasn't drawn already by the iteration for when the mark is on.

Also make the conditions involving horizontal scrolling more precise.

Instead of saving the current value of placewewant, then setting the
new value, and then passing the old value to edit_redraw() in seven
different places, just let edit_redraw() do this saving and setting.

In the bargain placewewant is now only recalculated when it matters
-- when allow_update is TRUE -- and not when it's superfluous.

Add a third mode of scrolling, FLOWING, besides CENTERING and STATIONARY.
This is used for word and paragraph jumping (and for bracket matching,
but that worked correctly already), and only when focusing is FALSE.

The new mode prevents the screen from scrolling too many lines when
there are several blank lines at the bottom of the edit window and
the next word or paragraph is out of view.

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

On iTerm2 on OS X, the Option+Arrow keys produce special sequences
that start with two escapes.  Catch these sequences and interpret
them appropriately as WordLeft / WordRight / Home / End.
Signed-off-by: Mike Scalora <mike@scalora.org>
Signed-off-by: Thomas Rosenau <thomasr@fantasymail.de>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>

git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5778 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

for aptness, for contrast.


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5777 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

invalid escape sequence, and when entering a verbatim keystroke.
But leaving the cursor off during Unicode input, for extra feedback.


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5771 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5769 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

anyway, and it will be placed back when it's needed: in the main loop.

This prevents a segfault laid bare by r5763: when trying, at startup,
to open a directory, there really is no open buffer yet.


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5766 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5765 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5764 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

variable for a little optimization.

Openfile can never be NULL -- it should have been called openbuffer, and
before we start fiddling with the cursor, we will always have an open buffer.
Edittop might be NULL, but that's okay.


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5763 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

tmp* is something for 5 lines, not for 300.


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5734 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5673 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

unrecognized escape sequence.


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5667 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5660 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

eliding two silly calls of edit_redraw().


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5650 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

needed), so that it no longer shows in the help screen nor in the file list.
This fixes Savannah bug #47126.


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5640 35c25a1d-7b9e-4130-9fde-d3aeb78583b8