Run the formatting program outside of curses mode, so that any output
(complaints) that it produces will be on the terminal after exiting
from nano -- at least on a terminal emulator, not on a Linux VT.
This also allows the formatter to be an interactive program.
The disadvantage is that the screen flickers when typing M-F.
This fixes https://savannah.gnu.org/bugs/?57104.
For a nonzero exit status of the formatting program, report on the
status bar that the program "complained", but read in the (probably)
reformatted text anyway -- it can be easily undone with M-U. Only
report failure when the intended program could not be run.
This fixes https://savannah.gnu.org/bugs/?57105.
The word "fixer" sounds too much as if the command would be able
to fix mistakes or correct errors. Especially when seen next to
"linter", it sounds as if one does a syntax check and the other
fixes the found mistakes. (Although the command might in theory
be used for this, it is not its intended purpose.)
After the previous change, all remaining calls of parse_mbchar() have
NULL as their third parameter. So, drop that parameter and remove the
chunk of code that handles it. Also rename the function, as there are
already too many functions that start with "parse".
Now all calls of mallocstrncpy() have NULL as the first parameter
(apart from one call in utils.c, but that can be changed), so the
function can be simplified.
The command can be used to run some kind of formatter or corrector or
arranging tool on the buffer. By default the command is bound to M-F.
The formatter/corrector/arranging program must be non-interactive.
This addresses https://savannah.gnu.org/bugs/?55365,
and addresses https://savannah.gnu.org/bugs/?54651.
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.
Benno Schulenberg