Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>

Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>

When multiple files were open and [x/n] was being shown in the title
bar, don't show nano's name and version number when just one buffer
remains open, but show [1/1] instead.  It is less surprising.

When multiple buffers are open, replace nano's name and version number
with an indication how many buffers are open preceded by the sequence
number of the current buffer.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

And use these constants in another context too.

Also rename a variable, to match the saving routine.

Also, reduce the scope of the 'line' variable.

Also, don't depend on statting the relative path, because if that would
fail, we would try to open a NULL pointer.

Further, slightly reword an error message so it is appropriate also
when an out-of-bounds file is specified on the command line.

There is no need to retain the (relative) path that the user
specified, so we can simply reuse that variable.

It would be horrible if the user expects to find numbered backups
of all the files that were changed but they are NOT there because
the config file contains a typo or the relevant directory was moved
or renamed or something.  So... if the specified backup directory
is not usable, nano should complain and simply not start up.

Discarding (in commit 6f9bb53b) the cap on the number of chunks to
move backwards had as an unforeseen side effect that the screen can
fail to scroll when the cursor is somehow pushed offscreen.

Fix this by setting the target row (for smooth scrolling) always to
the bottom row of the edit window when nano notices that the cursor
has gone offscreen.

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

.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>

Without them, nano still compiles for me, with everything enabled,
even when using --enable-debug, --enable-utf8, and --with-slang.

The function place_the_cursor() assumes that the viewport is up to date,
i.e., that current is in range of edittop.  When uncutting or inserting,
however, place_the_cursor() gets called on the out-of-date viewport
first, and then a screen refresh is scheduled (which would put the
viewport up to date).  This is backwards: the refresh should come before
the cursor placement, and the only reason it works anyway is because the
cap on the number of chunks to move backward papers over the problem by
keeping current_y in screen range regardless.

Fix this properly by simply setting current_y to the bottom row of the
screen instead of calling place_the_cursor().  This value of current_y
is only ever used when in smooth scrolling mode and the insertion (or
paste) pushed the cursor offscreen.  In other situations, this value is
overridden when place_the_cursor() gets called after a screen refresh.

After that fix, the cap on the number of chunks to move backward is no
longer needed.

Counting the added number of rows is only relevant when inserting
a file into the current buffer.  So don't waste time counting when
it's not needed.

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

The help lines need to be redrawn one step after a justification
(whether it has been undone or not, to replace "Unjustify" with
"Uncut" again for ^U), and after switching buffers (to update a
possibly changed tag for ^T).

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

The precalculation of the multiline regexes no longer looks at the
keyboard every second, and the backup code makes use of futimens()
nowadays.

Well, it will compile even without that include.  :|
I don't know why, since it does use va_list.

get_chunk_row() replaces the formula "column / editwincols".

get_chunk_leftedge() replaces "(column / editwincols) * editwincols".

get_last_chunk_row() replaces "strlenpt() / editwincols".

get_last_chunk_leftedge() replaces "(strlenpt() / editwincols) * editwincols".

This prepares us for any changes in those formulas, and for more such
functions later.

This partially adresses https://savannah.gnu.org/bugs/?50998.

It's useless, because the position doesn't get restored, and it
cannot be restored because the name is different every time.

This extra question was included upon Chris' request, but I find it
confusing and angering.

When spotlighting the string to be replaced, placewewant isn't valid,
so tell place_the_cursor() to ignore its value to avoid the cursor
getting mistakenly placed at the beginning of the next row.

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

.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>