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>
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>
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.
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.
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>
Things have morphed over time and display_buffer() no longer actually
displays the buffer -- it just displays the title bar, precalculates
the multiline color info, and schedules a refresh of the edit window.
This avoids https://savannah.gnu.org/bugs/?49912 while at the same time
avoiding to draw the edit window twice in a row -- the first drawing
would use a wrong margin, which results in a visible and irritating
shift left or right of the content upon the second drawing.
This fixes https://savannah.gnu.org/bugs/?50877.
When nano has multiple files open, closing a help buffer should
not switch to the next buffer in the ring but to the preceding one,
because it was from there that the help screen was invoked.
Allow the user to search in a help text with ^W and M-W.
Achieve this by not writing the help text directly to the screen
but first writing it to a temporary file and then opening this file
in a new buffer, and treating it specially: the normal file-reading
feedback is suppressed, the titlebar shows the headline of the text,
the cursor is hidden, and the menu is limited to just the up and down
movements and searching.
This fulfills https://savannah.gnu.org/bugs/?28994.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Call something a buffer when it refers to a linked list of linestructs,
and call something a linestruct when it is a struct that describes a
single line.
