Print routines are not asynchronous-safe.
But... the only reason the call of kill() could return an error code
is when the relevant process has already terminated -- which is not
a problem, because that was the goal of calling kill().
This fixes https://savannah.gnu.org/bugs/?54409.
Reported-by: Daniel Kozovsky <dkozovsk@redhat.com>
The undo item for ENTER should record the file size *before* the amount
of auto-indentation whitespace is added to it.
This fixes https://savannah.gnu.org/bugs/?54344.
Reported-by: Liu Hao <lh_mouse@126.com>
Instead of being entirely silent when ^] is hit after whitespace
or punctuation, report what is lacking -- similar to M-] saying
"Not a bracket" when the cursor is not sitting on a bracket.
This makes the ^] keystroke more discoverable.
Take our cue from undoing/redoing line joins: when they take place on
the magicline without --nonewlines, they produce undo/redo items that
don't do anything to the text, but still position the cursor properly.
Reshuffle a bit of code so that we can do the same for magicline cuts.
This fixes https://savannah.gnu.org/bugs/?54032.
The variable 'last_action' is set at the end of these functions,
serving to prevent a fresh action from being merged with an older
action further down on the stack. Setting 'last_action' before
exiting from undo()/redo() makes no sense.
Also adjust a sideways related old Changelog item.
The macro stuff, however, is basically my code: I told him exactly
how to do it, and I changed most of the patch before applying it.
Also, put myself in second place, as I've just about overtaken David
in the duration of maintainership.
The paragraph-aware indenting is needed only when automatic long-line
wrapping is on (that is, when not using 'nowrap': when writing prose).
When writing code, the user most likely uses --nowrap, which will make
nano indent a new line always to the same amount as the preceding line
-- when --autoindent is in effect, of course.
When doing autoindentation, and the next line is not the start of
a new paragraph, then use the indentation of that line for the new
line, as it is more likely to have the desired indentation -- the
current line might be the start of the paragraph and thus could
have a deviant indentation.
Pico wraps at the last blank character before or on the target column;
if there is no such blank, then it will wrap at the first blank *after*
the target column -- when it can wrap, it will wrap. Nano should do
the same (and judging from the comments, it intended to do the same),
instead of turning the paragraph into a single unwrapped line.
This fixes https://savannah.gnu.org/bugs/?53986.
First step to the next buffer, and then iterate until we either
find a match or are back at the buffer where we started.
This fixes https://savannah.gnu.org/bugs/?53970.
Signed-off-by: Marco Diego Aurélio Mesquita <address@hidden>
The two help lines will be redrawn in main() only when the current
menu is not MMAIN. So, set it to MLINTER as soon as the help lines
are cleared, just before preparing to invoke the linter.
This fixes https://savannah.gnu.org/bugs/?53967.
Reported-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
When executing a command in the current buffer and piping this buffer
(or marked region) to that command, then the cutting of the existing
text and the insertion of the new text should be undone and redone
together, as to the user they appear as a single operation.
With-help-from: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
When executing a command, it is now possible to pipe the entire buffer
(or the marked region, if anything is marked) to the external command.
The output from the command replaces the buffer (or the marked region),
or goes to a new buffer.
This fulfills https://savannah.gnu.org/bugs/?28993,
and fulfills https://savannah.gnu.org/bugs/?53041.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
When 'afterends' is set and Ctrl+Right or Shift+Ctrl+Right is pressed,
nano will stop at the ends of words instead of their beginnings.
Signed-off-by: Mark-Weston <markweston@cock.li>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Set the NO_NEWLINES flag to achieve this. And move the saving and
restoring of the global flags to the main speller routine, so the
flags aren't saved and restored for each internal spell fix.
This fixes https://savannah.gnu.org/bugs/?53742.
Acked-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug existed since commit 30fc197b (a month ago) which changed the
type of 'i' from int to size_t, causing the comparison to do the
wrong thing when 'threshold' is negative.
This fixes https://savannah.gnu.org/bugs/?53722.
Reported-by: Devin Hussey <husseydevin@gmail.com>
The formatter or linter might have changed in the meantime -- when
the filename was changed to have a different extension, for example.
This fixes https://savannah.gnu.org/bugs/?53716.
Indenting/unindenting always happens in a single contiguous block.
Lines that cannot or should not be indented or unindented do not
need to remembered separately as it follows from their content.
In the preceding commit, open_buffer() was changed so that it gets
told whether to load into a new buffer or not, so it is no longer
needed to convey this information through a flag.
This fixes https://savannah.gnu.org/bugs/?53269.
Reported-by: Ashish Kunwar <dorkerdevil280@gmail.com>
The leak was mistakenly introduced by commit dc3618a1
-- probably as a leftover of testing things.
First the two that add something (ADD, ENTER), then the three that
delete something (BACK, DEL, JOIN), and then the one that changes
something (REPLACE). Then the SPLITs, CUT, PASTE, and INSERT, and
then the INDENTs and COMMENTs, when they exist.
For cuts, pastes, and inserts, the lines have already been renumbered;
for indents, comments, and replacements, the line numbers cannot have
changed. (And anyway, variable 'f' is not set for those cases.)
Only when lines get split (ENTER) or fused together (JOIN) do the later
lines need to be renumbered. This mirrors what is done for do_redo().
The 'f' variable is used only in the ADD, BACK, DEL, ENTER, JOIN, and
REPLACE undo/redo cases. So, avoid making a somewhat costly call when
it is entirely superfluous. Rearrange the undo types to make checking
for the above six types easier.
When using --smooth or 'set smooth', the screen should scroll the
minimum amount needed to get the cursor back into view. (The only
exceptions are search, undo, and redo -- when there the cursor goes
offscreen, the cursor line is centered.)
This change brings the behavior of pressing <Enter> on the bottom
row into line with, for example, pasting a single line. See also
http://lists.gnu.org/archive/html/nano-devel/2018-02/msg00027.html.
Trimming trailing spaces is good, but we should not trim the space
(or tab or other blank) that the user just typed and that caused the
hard-wrapping to occur.
This fixes https://savannah.gnu.org/bugs/?52948.
Reported-by: Andreas Schamanek <schamane@fam.tuwien.ac.at>
Each leading tab is converted to two tabs, and any leading four spaces
is converted to one tab. The intended tab size (for keeping most lines
within 80 columns) is now four.