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>

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

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.

Instead compute directly whether we're at a softwrapped part or not.

Convert digits() to take a ssize_t instead of an int, since it's
used on ssize_t line numbers.  And properly use the long modifier
when displaying a line number.

Also, conditionalize the digits() prototype.

This addresses https://savannah.gnu.org/bugs/?49803.

But do it correctly this time: don't switch it on when replacing.

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

Modern VTE-based terminals now produce codes for those keys and
no longer swallow them when nano is active.

This addresses https://savannah.gnu.org/bugs/?49746.

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

Achieve this by reusing the code that gives feedback when trying to
save a buffer while using --tempfile and the file has no name yet.

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

Also for Delete, End, PageUp and PageDown (on some terminals)
the last byte in the sequence needs to be checked.

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

That is: when --rebindkeypad is in effect -- without this option
they were already getting distinguished.

Both would jump a word to the left -- now each jumps a word in the
proper direction.

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

It does not update anything -- it just picks a new point from
where to start displaying the buffer.  All actual updating of
the screen is done by edit_refresh() and edit_redraw() and such.

There is no need to look at this for every painted line, because
the margin can only change when some key is struck.

Instead of doing this in two places: after interpreting shortcuts,
and after injecting characters.

To prevent the display from getting messed up, making nano unusable.

It can be activated with --linenumbers on the command line or with
'set linenumbers' in a nanorc file, and it can be toggled with M-#.
Signed-off-by: Faissal Bensefia <faissaloo@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>

This fixes https://savannah.gnu.org/bugs/?49058 reported by Rishabh Dave.

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

This fixes https://savannah.gnu.org/bugs/?47710
and fixes https://savannah.gnu.org/bugs/?49088.

Returning a zero would mean returning a ^Space -- the keycode that
by default is bound to the Next-Word function.  So, unbinding the
keys to which the modified Arrow keys are hard bound would cause
the latter ones to mysteriously jump to the next word.

This partially fixes https://savannah.gnu.org/bugs/?49058.

This fixes https://savannah.gnu.org/bugs/index.php?42189.

And also case-sensitive searches, backward searches, and searching again.