When an operation that replaces the entire buffer is undone, the
position of the viewport is lost. Compensate for this by storing
the row of the cursor in the undo item, and, after executing the
undo item, arranging the viewport so that the cursor is back on
the original row -- the row where the operation was invoked.
This fixes https://savannah.gnu.org/bugs/?57039.
For the three operations (justification, spell checking, and filtering)
that need to undo or redo two suboperations (cutting and then pasting)
in one go, pass the message that describes the operation to add_undo(),
so that the undo item does not need to be modified after the call.
This looks better, but does add some twenty NULL parameters elsewhere.
The 'tabgives' command is syntax-specific and should be followed by a
string containing the character(s) that a single press of the <Tab> key
should produce -- most likely a single TAB or a small bunch of spaces,
but any string is allowed. This overrides the 'tabstospaces' option.
When one wants to make sure <Tab> inserts always four spaces and never
a TAB when editing a Python file, one could add to one's nanorc:
extendsyntax python tabgives " "
where there are four spaces between the quotes. And when one wants
to ensure, when editing a Makefile, that <Tab> always inserts a TAB
and never spaces, independent of what tabstospaces is set to, one
could add to one's nanorc:
extendsyntax makefile tabgives " "
where there is a literal TAB character between the quotes.
This fulfills https://savannah.gnu.org/bugs/?53661,
Requested-by: Andrew Pennebaker <andrew.pennebaker@gmail.com>
And addresses https://savannah.gnu.org/bugs/?54760.
Requested-by: Henry van Megen <hvanmegen@gmail.com>
And addresses part of https://savannah.gnu.org/bugs/?54775.
Requested-by: Dirkjan Ochtman <dirkjan@ochtman.nl>
When the user is typing a long text and --breaklonglines is in effect,
then any leading comment or quoting characters are automatically added
to each automatic new line.
This fulfills https://savannah.gnu.org/bugs/?56042.
Requested-by: Sébastien Desreux <seb@h-k.fr>
Instead of calling in twenty places parse_mbchar(pointer, NULL, NULL),
use a simpler and faster char_length(pointer). This saves pushing two
unneeded parameters onto the stack, avoids two needless ifs, and elides
an intermediate variable.
Its main purpose will follow in a later commit: to speed up searching.
There is no need to make a copy of the line, because if there are some
bytes that are moved, they are always moved toward the left -- the line
can only shrink, never expand.
When squeezing excess spaces from a line has proved unsuccessful, we
have already copied all of its data, so it hardly makes a difference
whether we free the old or the new data. Choose to free always the
old data, so that we can simplify things.
There is no need to save, clear, and restore the mark when counting
words, lines and characters, because partitioning and unpartitioning
the buffer does not use the mark nor affect it.
Now M-D will report 0 lines instead of 1 line for an empty buffer, and
will match the output of 'wc --lines' as long the file is a POSIX file.
This fixes https://savannah.gnu.org/bugs/?56054.
Bug existed since before version 2.1.10.
For this one quick switch back and forth there is no need to report
anything on the status bar nor to update colors and such. In this
case, those things are just a waste of time.
No one ever reported seeing the message that was removed in commit
c039aaad one month ago, so most likely the code is correct and nano
never calls line_from_number() with a non-existent line number.
For both an integrated and an external spell check, fake the Shift key
being held so that (when the cursor is moved by a changed length of a
word) a Shift-selected region is not unexpectedly cancelled.
This fixes https://savannah.gnu.org/bugs/?56365.
Don't bother checking for an error from sigaction(), because the only
things it could error out for is when it is passed an invalid signal
(which SIGINT isn't) or oldaction/newaction would point to memory that
is outside of nano's control (which is obviously not the case).
Also, the setup of signal handlers during startup does not check for
errors, so why do it here?
If functions deeper down would put up some message on the status bar,
it should not be cleared. The chance that messages from a spell-check
program stay onscreen is minute: the edit window is fully refreshed,
the status bar is fully drawn, and the help lines (if there are any)
are redrawn. Only the title bar is not refreshed, but the chance that
an error message has spilled onto the top row... And anyway, the
spell checker should not print any error messages at all.
Benno Schulenberg