Consecutive additions all happen on the same line. When automatic
hard-wrapping occurs, the ADD item is grouped together with an ENTER
item, and subsequent additions go into a new ADD item.
Either the marked region was cut (even when zero characters) or
the entire contents of the buffer were cut. In both cases this
is what needs to be piped to the command. That is: the contents
of the cutbuffer.
This fixes https://savannah.gnu.org/bugs/?57931.
Bug existed since version 2.9.8, commit f304b9ae,
when piping text to an external command was introduced.
Allow the creation of an empty CUT undo item (because the result of a
filtering operation may be empty), but then don't crash when undoing
such an empty CUT.
This fixes https://savannah.gnu.org/bugs/?57929.
Bug existed since version 2.9.8, when filtering was introduced.
Trying to do so would dereference a NULL pointer in copy_node().
This fixes https://savannah.gnu.org/bugs/?57915.
Bug existed since before version 2.2.0.
Also, remove two superfluous closings of file descriptors. The second
one has most likely already been closed by send_data(), by closing the
tube, and the first one will be closed by exiting from the process.
Also, avoid two superfluous assignments of a message, as they get
overwritten immediately by other ones, and later with the same.
Furthermore, remove two pointless placements of the cursor. Any
necessary placements are handled by the actual adding of data and
the breaking of lines in the ADD and ENTER items.
Especially when undoing an addition, reallocating the line data is a
waste of time, because most likely other text will be added instead.
(This also removes a coding error in the redo code for a deletion:
it allocated too many bytes for the new line data: twice the amount
of the deletion too much.)
I don't know what I was thinking three years ago with this convoluted
'from_x' and 'to_x'. When undoing an <Enter>, the cursor always needs
to be placed back at the 'head' point. And the data always needs to be
copied starting from 'tail_x' (skipping any whitespace that autoindent
might have added).
When redoing an <Enter>, there is no need to reallocate and copy the
data of the line, it is enough to just clip it at the original cursor
position. (This wastes some memory, but... how often does one redo
an <Enter>? So, conciseness of the code is preferable.)
And before the buffer size is adjusted, so that the add_undo()
doesn't need to correct the stored former size of the buffer.
This will allow the injection of multiple characters at once,
in the next commit.
The SPLIT_BEGIN item gets tucked underneath the ADD item on the top of
the undo stack. Thus: that SPLIT_BEGIN item should copy the 'wassize'
of the ADD item instead of storing the current buffer size.
This fixes https://savannah.gnu.org/bugs/?57832.
Bug existed since the undo functionality was added, and existed
in this form since version 2.3.5, commit be10c2a4.
In theory this would allow injecting more than one character at a time
into the edit buffer. But the creation and updating of an undo item for
the addition or the deletion of a character are a bit strange. For all
other operations and add_undo() is called before the operation, and an
update_undo() afterward. But for an ADD, the add_undo() is called after
the operation, and for a DEL/BACK, the update_undo() is called before
the operation. There is some logic to that, but things would be easier
to understand if all operations were handled the same: an add_undo()
beforehand (when needed), and an update_undo() afterward.
When something is pasted or inserted onto the final, empty line of a
buffer, an automatic new magic line is created after it, when needed.
When this paste or insertion is undone, the added magic line should
also be removed again.
This fixes https://savannah.gnu.org/bugs/?57808.
Bug existed since the undo capabilities were added,
since before version 2.3.0.
The few calls of the injection routines that had 'filtering' set to
TRUE have already filtered out ASCII control codes earlier on. And
in the case of injecting a completion, this completion only contains
word-forming characters -- and if the user somehow added a control
code to the word-forming characters, then nano should NOT filter it
out, so in fact that setting of 'filtering' to TRUE was mistaken.
Note that this filtering did not filter out 0x7F (DEL). But that is
fine: it should not occur in the input stream at that point anyway,
as it gets translated to either KEY_DC or KEY_BACKSPACE earlier in
the keyboard parsing routines.
Since the previous commit, nano exits from curses mode soon after
this message is printed, so that the user does not have any time
to read it or even see it.
When invoking the "internal" speller, leave curses mode while the three
programs in the pipe array are executing, to prevent 'hunspell' from
writing a long error message to the end of the status bar, making the
screen scroll, and thus messing it up. Now the error message gets
printed to the screen that nano was started up from, and will thus be
visible when the user exits from nano. (At least: it will be so on a
terminal emulator -- on a VT, nothing will be seen.)
This fixes https://savannah.gnu.org/bugs/?57728.
Bug existed since version 4.6, commit 4d77e0ad.
At that point, 'u->cutbuffer' will always be NULL, either from the
original creation of the INSERT undo item, or by having been freed
and set to NULL by do_redo().
Just like nano beeps when an unbound key is pressed at other prompts,
or in the help viewer, or in the file browser.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
The suppression of auto-indentation, automatic hard-wrapping, and
tab-to-spaces conversion is now inherent in the way the reading-in
of a bracketed paste is handled by the previous commit: as a single
block of text.
Also, do not break overlong lines and do not convert tabs to spaces,
nor interpret a <Tab> as an indent command (when the mark is on).
In other words: accept an outside paste as literally as possible.
This fulfills https://savannah.gnu.org/bugs/?40060.
Requested-by: Egmont Koblinger <egmont@gmail.com>
And fulfills https://savannah.gnu.org/bugs/?57527.
Requested-by: Sébastien Desreux <seb@h-k.fr>
Requested-by: Hans Ecke <hecke@gxt.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
When justifying a paragraph, always first squeeze() is called on
the text (which at that moment consists of a single long line),
which means that (in its wrappable part) this line contains only
single spaces as word separators (and maybe a double space after
a period). So there is no need to call the general is_blank()
function -- checking for a space is enough.
Rationale: nano should not wrap inside the quoting part of a line
because it would change the quoting level, which would misrepresent
things, nor should it wrap inside the indentation part because when
the user tries to indent something beyond the target wrapping width,
she/he does not intend to create a line containing only whitespace,
but effectively wants to push the text beyond the wrapping width.
This copies the behavior of the rewrap_paragraph() routine that is
used during justification, so that automatic hard-wrapping ends up
with the same result as justifying.
Also, always do automatic hard-wrapping when --breaklonglines is in
effect, also when --autoindent is active.
This fixes https://savannah.gnu.org/bugs/?57425.
The bug was old -- it existed since at least version 2.0.6.
This furthermore avoids https://savannah.gnu.org/bugs/?57422.
Reported-by: Sébastien Desreux <seb@h-k.fr>
That bug existed since version 4.4, commit 8fce33af.
That is: allow tabs and spaces to be mixed when comparing indentation.
When the mix of tabs and spaces pushes the text of a line to the same
column as on a consecutive line, then those two lines are considered
to have the same indentation and thus belong to the same paragraph.
This reverts the previous commit (594ef222), and improves upon how
nano has behaved since version 2.9.8.
This fixes https://savannah.gnu.org/bugs/?57404 differently.
That is: two consecutive lines are considered to belong to separate
paragraphs when the smallest indentation of those two lines is not
character-by-character identical with the corresponding piece of
indentation of the other line.
In other words: if one line is indented with spaces, and a consecutive
line is indented by the same distance but with tabs, they are taken to
belong to different paragraphs: a justification will not merge them.
This fixes https://savannah.gnu.org/bugs/?57404.
Bug existed since version 2.9.8, commit 432a7d77.
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.
Benno Schulenberg