When doing replacements or fixing misspelled words, and edit_refresh()
is called to highlight the relevant word, then the current menu can be
anything from MREPLACEWITH, MYESNO, MSPELL, or MMAIN. Make sure it is
always set to the latter just before calling edit_refresh(), so that
display_string() will use the full length and the word gets properly
highlighted.
This fixes https://savannah.gnu.org/bugs/?55680.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug was introduced by the previous commit, 56181896.
The reduced file size should be stored not just when joining two lines
but also when simply a character in the middle of a line is deleted.
This fixes https://savannah.gnu.org/bugs/?55352.
Bug existed since version 2.5.0, commit 66e21416.
Reuse the WAS_FINAL_LINE flag to signal a cut that added a magicline,
for both a marked cut and cut-to-eof.
This fixes https://savannah.gnu.org/bugs/?55305.
The direct call was a leftover of the old unjustify mechanism.
Also, move two statements to the end of the do_justify() routine,
since that is their place in comparable routines.
Suggested-by: David Lawrence Ramsey <pooka109@gmail.com>
Not stepping beyond the last line of the paragraph means that the
length of the paragraph is always the difference in line numbers
(between first and last line of the paragraph) plus one.
When leaving the mark on while justifying and then undoing the
justification, things are likely to get messed up. My applying
David's patches only partially caused this breakage.
This fixes https://savannah.gnu.org/bugs/?55074.
Only the first search for a paragraph needs to check whether we're
currently in the middle of a paragraph. When the 'while' loop for
a full justify is executed, all calls of find_paragraph() start
either on the first line of a paragraph or between two paragraphs.
To find a paragraph, what needs to be done is:
a) When not in a paragraph, move forward until we find one, if any.
b) When in a paragraph but not at its start, move back to its start.
c) Move forward to the end of the paragraph, if any.
When, in the 'while' loop for a full justify, 'filebot_inpar' becomes
TRUE, it means that EOF has been reached and find_paragraph() should
not be called again. To allow 'filebot_inpar' to convey this meaning,
it should not be set to TRUE elsewhere, so another boolean is needed
for setting the correct length of the final line of the cutbuffer.
This fixes https://savannah.gnu.org/bugs/?55086.
The removal of the x-coordinate handling affected this. Reshuffle things
so that we can check for it after we have moved (the same way we check for
it at the beginning of the function before we move) without having to set
'quote_len' and 'par_len' unnecessarily.
Also, adjust some comments accordingly.
Move detecting the final line of the paragraph to find_paragraph(),
since a paragraph of which the final line is the last line of the
buffer will still be that way after being justified.
Also, move all x-coordinate handling to do_justify(), since it only
applies to the current buffer.
Move a few references to the current buffer to do_justify(). Also,
the check for being at the end of the buffer needs to be done after the
first paragraph is found, so that the existing behavior of finding an
initial paragraph regardless of cursor position is preserved.
The functions do_para_begin() and do_para_end() can now move through any
buffer, while the functions do_para_begin_void() and do_para_end_void()
operate on the current buffer. The latter function also returns TRUE
if the last line in the buffer is part of the paragraph.
Remove the handling of 'edittop', 'totsize', and the mark, to make the
function more general, which is needed to make it undoable eventually.
This breaks the function somewhat. Fixes for this are forthcoming.
The function assumes that it works on the current buffer by handling
'totsize' and the mark. Remove this handling to make the function
more general, which is needed to make it undoable eventually.
This breaks the function somewhat. Fixes for this are forthcoming.
Using --zap or -Z on the command line, or 'set zap' in a nanorc file,
makes the <Bsp> and <Del> keys erase selected text (a marked region)
as they do in some other editors, and without affecting the cutbuffer.
This fulfills https://savannah.gnu.org/bugs/?54837.
Requested-by: Liu Hao <lh_mouse@126.com>
Signed-off-by: Brand Huntsman <alpha@qzx.com>
This function allows the user to "make space": annihilating lines or
regions while keeping intact for pasting the stuff in the cutbuffer
that was cut or copied earlier.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
Return immediately to editing mode when there are no messages for
the original file and the user does not wish to open any of the
included files that do have messages.
Also, reword the message that the linter gives then, and leave it
on the status bar (just like when Cancel is pressed).
The help lines will help differentiate this mode from normal editing
mode, and will tell the user how to jump to other messages.
This is a third step to address https://savannah.gnu.org/bugs/?54714.
When something is spotlighted, it should survive a refresh of
the screen and an excursion to a help text, so the spotlight
should get painted whenever the edit window is drawn.
This fully fixes https://savannah.gnu.org/bugs/?54721.
The new function, justify_paragraph(), takes a quote length and a
paragraph length (which it should get from find_paragraph()), and
runs the paragraph at (current, current_x) through justify_format().
Move some fragments out of the justifying loop, and adjust/clarify comments
to account for the changes. This will allow some of the code to be cleaned
up and simplified in the next commits.
Only for BACK and DEL was the first call to update_undo() -- all other
types of action would call add_undo() first, so for them the action in
update_undo() would never be different, but the line number might have
changed (like for ENTER and INSERT), so for them exceptions needed to
be made, which was wasteful.
This addresses https://savannah.gnu.org/bugs/?54728.
When using the internal spell checker, the message gets overwritten
immediately by "Creating misspelled word list...", and when using
the external spell checker, nano immediately exits from curses mode
and thus the message disappears (when in a terminal emulator) or it
soon gets wiped by the spell checker (when on a Linux console), thus
creating a little flash on the bottom row, which we can do without.
In the past, SIGWINCHes were responded to immediately (which was madness),
but since commit 75d64e67 all a SIGWINCH does is set a flag so that, when
the time comes to update the screen, nano knows the dimensions may have
changed. The mentioned commit removed most blockings and unblockings of
SIGWINCH, but not this one.
That is, wait with deleting words until they start under cursor,
so the user can see which word is goin to be eaten, and join lines
only when the cursor already sits at the edge of a line.
If find_paragraph() detects that we're not in a paragraph, it moves
forward a paragraph and then backward to that paragraph's beginning.
Make it check whether we're in a paragraph before moving backward
(since there might not *be* any more paragraphs), to prevent going
forth-and-back and never reaching the end of the buffer.
This fixes https://savannah.gnu.org/bugs/?54573.
And restore the cursor to this position when redoing the cut+insert.
Also remove two unneeded conditions.
This fully fixes https://savannah.gnu.org/bugs/?54466.
When piping the buffer (or the marked region) to an external command,
we should wait not only for the external command to terminate but also
for the data-sending process, so that it will release its resources.
This fixes https://savannah.gnu.org/bugs/?54499.
With-help-from: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
When undoing/redoing an alternate spell check (of the entire file
or of a backwards marked region), put the cursor back where it was
when the spell check was invoked/finished.
This fixes https://savannah.gnu.org/bugs/?54466.
Since the last version, the user can filter an entire buffer through
an external command. This external command can also be a formatting
program, so there is no longer any need for this specific and special
formatter command.
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.
If the marked region ends at the start of a line, do not include that
line in the indenting/undenting or commenting/uncommenting. This is
closer to what the eye would expect.
Unset the "Modified" marker only at the point where the file was last
saved -- if there is such a point, because it can be missing when the
undo stack was discarded.
This fixes https://savannah.gnu.org/bugs/?52689.
Reported-by: Liu Hao <lh_mouse@126.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
And also allow it when lines are only partially indented.
This makes it possible to equalize the indentations of (accidentally)
unevenly indented lines: by first fully unindenting a group of lines,
and then reindenting them to the desired amount.
Suggested-by: Liu Hao <lh_mouse@126.com>
When the WAS_FINAL_LINE flag is relevant (when NO_NEWLINES isn't set),
the only way for 'current' to be equal to 'filebot' is when 'current_x'
is zero.
When some or all edits have been undone, and the user starts to make
new edits, the old part of the undo stack is discarded, but this does
not mean that the undo stack doesn't go back to the very beginning.
This really fixes https://savannah.gnu.org/bugs/?52504.
This also means that no question needs to be asked when exiting.
This fixes https://savannah.gnu.org/bugs/?52504.
Reported-by: Peter Passchier <peter@passchier.net>
The pointer not being NULL is enough indication that the mark is set.
Also, rename the pointer from 'mark_begin' to simply 'mark', since
the former is kind of pleonastic.
Because the highlighting hinders the display of affected lines,
and, more importantly, only the highlighted part would be written
if the file was modified and the user answers yes to the "Save?"
prompt.
This fixes https://savannah.gnu.org/bugs/?52474.
In the tiny version, do_prompt() will now have an extra NULL
parameter, which will cost maybe twenty extra bytes of code.
That is acceptable when it saves thirty lines in the source.
Before writing a file out, nano should check that the file on disk
hasn't been modified since it was read -- not only for the normal
"Write Out" action (^O), but also for "Save File" (future ^S) and
for "Save and Exit" (^X when --tempfile is used).
When writing fails and --tempfile is in effect, don't go on to prompt
for a file name; instead let the user decide what she wants to do.
This fixes https://savannah.gnu.org/bugs/?51040.
Signed-off-by: Viorel Bota <botaviorel@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The basic idea is that the cursor is always off, except when it needs
to be on: when waiting for text input, and in a few other cases: when
something was searched and found in the help viewer, and in the file
browser when option -g is in effect.
This fixes https://savannah.gnu.org/bugs/?51923.
Reported-by: Mike Frysinger <vapier@gentoo.org>
This is modeled after the comment/uncomment code. Each line's
individual indent is saved in the string array of the undo
group structure.
This fixes http://savannah.gnu.org/bugs/?46860.
The function does not contain any comment-specific code, so it can
be used to handle any kind of multiline undo item.
Also, extend the undo group structure to contain an array of strings,
one for each line in the group. When indent/unindent is hooked up to
the undo/redo code, this will allow the latter to restore the exact
original indents.
Also, remove an unneeded null_at() -- the null byte has been copied,
and reallocating the string would recover very little memory.
Also, call charmove() without using the & operator.
This is modeled after the undo/redo code for commenting. do_indent() now
calls indent_a_line() on each line it covers. The latter function will
eventually be used by the undo/redo code.
The preceding 'for' loop has already established that all the lines are
either unindentable or composed of only blanks. So if now a line cannot
be unindented, it means it is fully blank, so it can be simply skipped.
This fixes https://savannah.gnu.org/bugs/?51760.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Also, only unindent when all selected lines can be unindented,
which means that the relative indentation will be preserved.
For this purpose, it ignores empty lines and lines consisting
of only whitespace.
When unindenting is not possible, a message is shown.
This fixes https://savannah.gnu.org/bugs/?47684.
Instead of inserting the extra whitespace after the current indentation
of a line, add it to the start of the line. This causes a fixed amount
of visual whitespace to be added regardless of whether --tabstospaces
is used or not.
This fixes http://savannah.gnu.org/bugs/?51438,
and its ancestor https://savannah.gnu.org/bugs/?51408.
Assume that a linter line that contains an actual error message or
warning includes a colon followed by a space -- something that that
opening message from a modern gcc lacks.
Benno Schulenberg