Do the same as in the previous commit: re-evaluate the start of the
viewport when lines that are located above this viewport may have
changed. This is relevant when softwrap is on.
When only the trailing chunk of a line is displayed on the top row of
the screen, and the unindenting of this line leads to a reduction in
the number of chunks, then the starting point of the viewport needs
to be re-evaluated. For simplicity, do this always when something is
unindented.
This fixes https://savannah.gnu.org/bugs/?56102.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since around version 2.9.2.
All other options are off by default and can only be switched *on*
(either by a command-line option or a nanorc setting) -- there are
no command-line options to switch them off again. Except for the
--breaklonglines/--nowrap pair. So these need special handling.
This fixes https://savannah.gnu.org/bugs/?56119.
Reported-by: Sébastien Desreux <seb@h-k.fr>
Bug existed since version 4.0, commit 4d40bea5.
When the file starts with one or more blank lines, the first paragraph
doesn't start on line 1.
This fixes https://savannah.gnu.org/bugs/?56117.
Bug existed since version 4.0, commit ac8bd2a2.
It is still possible to use --jumpyscrolling on the command line or
'set jumpyscrolling' in a nanorc file, but a user will have to restart
nano when they decide they want chunky instead of smooth scrolling,
a decision that should be rather rare.
This frees up the M-S keystroke to be reused for toggling softwrap.
The error messages from gnulib need to be included into nano's POT file
so that those messages get translated when nano is built on a platform
where the modules that contain the messages get used.
This fixes https://savannah.gnu.org/bugs/?56107.
Bug existed since gnulib support was added in version 2.8.0.
The relevant modules were added by commits 3deec435 and 272345cc.
For relatively inexperienced users (as most users of nano probably are)
it is far better that nano produces POSIX text files by default, where
each line ends with a newline character. This means that these files
will "print" properly (not gluing the next prompt at the end of the
last line), tools will see and process each line of them, and, while
editing, adding text at the end is easier.
This addresses https://savannah.gnu.org/bugs/?55997.
Reported-by: Ralph Corderoy <ralph@inputplus.co.uk>
Instead of doing a check every time round the loop when it is useful
only the first time, duplicate a bit a code and do the check and its
related action beforehand.
Also, improve some comments.
Also, find_bracket_match() is only called when there is a bracket under
the cursor, so stepping forward will never go beyond the end-of-line,
so the central loop does not need to check for that.
Also, improve a comment and shorten another, change a 'for' to a 'while'
(as the end point is not known), and rename a parameter from a single
letter to a word.
Some of these directives are now colored in their entirety, while for
a few others it's still just the keyword itself that is colored.
Signed-off-by: Liu Hao <lh_mouse@126.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The reading order must be predictable, otherwise things might get
colored differently from system to system.
This fixes https://savannah.gnu.org/bugs/?56012.
Otherwise the user could do something like
^R^X sed -i 's/a/surprise!/g' name-of-current-file <Enter>
and the file being viewed would be modified anyway.
The word "buffer" in relation to undo has been confusing to translators.
Also, drop the exclamation mark, as there is nothing important or urgent
about these messages.
Benno Schulenberg