Also, 'hunspell' is sensitive to the 'LANG' environment variable,
so that spell checking will take place for the language that the
user is using, instead of always for English. (This is a behavior
change, and some people may not like it, expecting the spell check
to occur always for English, but... we'll see.)
This increases the chances that spell checking will work out of the box,
without any extra installing or configuration.
This addresses https://savannah.gnu.org/bugs/?57296.
Also, when something goes wrong in the later stages of the pipeline,
the error code would try to close descriptors that are already closed,
which is not right. So, just let exit() handle any file descriptors
that are still open.
When something goes wrong, nano should beep and the status bar should
use the error color (red by default).
This fixes https://savannah.gnu.org/bugs/?57116.
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.
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.
The integrated spell checker does not use regular expressions, and
'refresh_needed' is set to TRUE anyway, so the tidy_up_after_search()
call there is effectively a no-op.
The lines from the cutbuffer will be renumbered when it matters: when
they get pasted.
The only place that used the numbering of (a copy of) the cutbuffer
(the updating of an undo item) already iterates through its lines.
Just add a counter there instead of making use of the line numbers.
All extractions are done into the cutbuffer, so it is pointless to pass
'cutbuffer' and 'cutbottom' in and back out as parameters all the time.
Just use those global variables directly.
Also, rename the function as there is no longer a buffer among its
parameters.
The 'cutbottom' variable is only ever used when cutting or copying
consecutive lines: for appending the current line to the already
existing lines in the cutbuffer. As soon as some other operation
is performed, 'cutbottom' becomes irrelevant, it could be set to
anything, it doesn't matter: the pasting of the cutbuffer does not
use the value of 'cutbottom', nor does any other operation.
Avoiding this leak is more trouble than it's worth: invocation_error()
will be called seldomly, and when it is called, the user will probably
quickly exit from nano to fix things.
Also declare the speller functions as const again, so they don't give
the impression that their result can be freed.
Suggested-by: Brand Huntsman <alpha@qzx.com>
Now you can have a look elsewhere in the buffer (and even delete
or paste stuff there) and when you return to the original line
and continue typing, any spillover from automatic hard-wrapping
will spill over onto the same line it spilled over to before.
You can even switch to a different buffer and return and continue
typing, and stuff will still spill over to the same line.
In the bargain, this gets rid of a bit of flag-resetting code
that was run for many keystrokes, in most cases needlessly.
This addresses https://savannah.gnu.org/bugs/?56189.
Most of the returned error messages are fixed strings, not allocated
strings.
This fixes https://savannah.gnu.org/bugs/?56188.
Reported-by: Aliaksei Sakovets <alexeysakovets@gmail.com>
Bug existed since version 4.1, commit f645009a.
When automatic hard-wrapping causes some piece of a line to be pushed
to the next line, then a separating space needs to be added at the tail
of this piece only when this piece actually gets prepended.
This fixes https://savannah.gnu.org/bugs/?56185.
Bug existed since version 2.9.2, commit 29f7654a.
When typing a space causes both the succeeding word and the cursor to
be pushed to the next line, then this space (and any contiguous ones)
does need to be snipped (when --trimblanks is in effect).
This fixes https://savannah.gnu.org/bugs/?56180.
Bug existed since version 2.9.3, commit 91073be4.
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.
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.
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.
Because somehow something goes wrong when SIGWINCHes are handled while
reading from a pipe.
This fixes https://savannah.gnu.org/bugs/?56011.
Bug existed since version 2.4.2, commit 75d64e67.
Some commands can take a little while to execute; showing just the prompt
during that time could give the impression that nothing is happening.
This addresses https://savannah.gnu.org/bugs/?56041.
When nano was configured with --enable-tiny --enable-speller, the
block_sigwinch() function should be available, to mask SIGWINCHes
during a spell check.
The blocking is needed only during the wait(), so unblock SIGWINCH
again right after the wait() -- also to have the unblocking before
a possible error exit.
Somehow a SIGWINCH pushes nano past the wait() in do_alt_speller(),
even though the external spelling program hasn't finished.
This fixes https://savannah.gnu.org/bugs/?56010
by reverting commit 1f39f60b.
Bug existed since version 3.2.
Since commit 4c6ec637 from about half a year ago, the 'action' parameter
of update_undo() is unused. Verify that this parameter matches the type
of the item at the top of the undo stack, so that in another half year
the parameter can be safely removed.
When the mark is off, initialize not just 'bot_x' but also 'top_x'.
This fixes https://savannah.gnu.org/bugs/?55898.
Bug existed since the justifying of a marked region was introduced,
four days ago, with commit f7f5514e.
This matches Pico's behavior. However, Pico doesn't add the quoting +
indentation to the line in which the selection ends, but this is wrong,
so nano does add it. Also, Pico doesn't account for partial quoting +
indentation at the start or end of a selection, but this is wrong, so
nano does.
Benno Schulenberg