The `gnulib` globbing module apparently does not handle an overload
of slashes well, so avoid feeding it more than it can take.
This fixes https://savannah.gnu.org/bugs/?65407.
Problem probably existed since version 2.3.3,
since globbing was introduced.
When the keystroke after the keystroke bound to `recordmacro` arrived
so quickly that the two got stored together in nano's keystroke buffer,
the main loop had not yet interpreted the `recordmacro` command and had
thus not yet set 'recording' to true, meaning that that second keystroke
would not get recorded.
Nano should record keystrokes into the macro buffer when fetching them
from its own keystroke buffer, not when fetching them from ncurses.
This fixes https://savannah.gnu.org/bugs/?65394.
The issue was reported by `correctmost`.
Bug existed since version 2.9.0, since macros were introduced.
During the Replace-With prompt the user could search in its help text,
which would overwite the 'last_search' string. Make therefore sure that
the latter gets restored to what it was before the Replace-With prompt.
This fixes https://savannah.gnu.org/bugs/?65381.
Bug existed since version 2.8.2,
since searching in a help text became possible.
Searching in a help text does not support using regular expressions,
so when 'inhelp' is set, do not free a compiled regex -- because if
there is such a regex, it belongs to a replacement session that is
about to begin.
This fixes https://savannah.gnu.org/bugs/?65369.
The issue was reported by `correctmost`.
Bug existed since version 2.8.2,
since searching in a help text became possible.
Only check input bytes when their count is nonzero.
This fixes https://savannah.gnu.org/bugs/?65365.
The issue was reported by `correctmost`.
The problem existed since version 5.7, commit c75a3839,
but occurred more easily since version 7.0, commit 75e5f885.
Translate mousewheel events into Alt+Up/Down key presses instead of
into plain Up/Down key presses, as the latter only start scrolling
once the cursor reaches the top or bottom.
Scrolling rather than moving the cursor is the standard behavior for
mousewheel events in GUI editors such as Gedit and Kate, as well as
in the mouse mode of terminal editors such as vim, joe, and mcedit.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
When --cutfromcursor is active, 'current_x' needs to be set to zero when
doing a justification, so that the correct starting position gets stored
in the undo item. (Without --cutfromcursor, the value of 'current_x'
does not matter.)
This fixes https://savannah.gnu.org/bugs/?65317.
The issue was indirectly reported by `correctmost`.
Bug existed in this form since version 5.0, commit ae5a4ece.
Between versions 4.0 and 5.0, nano would not eat a line but would
instead crash when undoing a justification that was done with the
cursor away from the left edge.
This stops the execution of a macro or a string bind whenever something
unexpected happens, to prevent the waiting keystrokes from doing things
that were not intended.
Especially this prevents an infinite loop: when during the recording
of a macro the `runmacro` keystroke is typed in some menu (where the
keystroke is not bound), and the macro is later replayed in a way that
results in exiting from that menu before the `runmacro` keystroke gets
replayed...
This fixes https://savannah.gnu.org/bugs/?65301.
The issue was reported by `correctmost`.
Bug existed since version 2.9.0, since the macro feature was introduced.
When --cutfromcursor is active, 'current_x' does need to be zero for
the segment extraction to do the right thing.
This fixes https://savannah.gnu.org/bugs/?65289.
The issue was indirectly reported by `correctmost`.
Bug existed since version 4.0, commit 2500debb.
When going back from the browser to a file prompt, restore the typing
position also after a 'to_first_file' (^Y) and 'to_last_file (^V).
The cursor misplacement existed since version 5.9, commit 508301a2.
When going back to a previous prompt, restore the typing position
also for 'to_first_line' (^Y) and 'to_last_line (^V).
This fixes https://savannah.gnu.org/bugs/?65278.
Bug existed since version 5.9, commit 6d5b1656, which allowed exiting
from a Search-in-help prompt with ^Y or ^V.
When the cursor is on the last line, and an undo removes this line,
do not let 'openfile->current' become invalid.
This fixes https://savannah.gnu.org/bugs/?65279.
Bug existed since version 6.3, commit eea3e1f0.
(It should have been fixed in commit 9410a556, more than a year ago.)
Commit 18b37c98 moved the bindings of ^H and ^D further down. Now move
the bindings of <Bsp> and <Del> to after those, so that ^H and ^D will
be shown again first in the help text (when not using --modernbindings).
This allows activating the "modern" bindings without having to pass an
option, by simply invoking nano through a symlink -- for example: `en`
(short for "editor nano"), or `et` (short for "edit"), or just `e`.
With --modernbindings, instead accept ^Q^X for abandoning any changes
-- the inverse of the normal (but undocumented) ^X^Q.
This prevents the unintentional loss of work when the user hits ^Q twice
by accident.
With --modernbindings, ^Q quits, ^F finds, ^B finds backwards, ^G finds
again, ^D finds again backwards, ^X cuts, ^C copies, ^V pastes, ^A sets
the mark, ^R replaces, ^O opens a file, ^W writes out a file, ^S saves,
^Z undoes, ^Y redoes, ^P shows the position, ^T goes to a given line,
and ^E executes.
Note that with --modernbindings ^Q and ^S are always bound, meaning that
--preserve / 'set preserve' is ignored. This is necessary because ^Q is
an essential keystroke in the modern bindings.
Also note that these "modern bindings" are effective only in the main
edit window, not in the various menus. In all menus ^C means Cancel,
and I can't think of a good alternative default keystroke for that
(in order for ^C to mean Copy). And in a few menus ^V has a meaning,
and there is no good alternative for that either. So... in the menus
the user has to use M-6 for Copy and ^U for Paste (and ^K for Erase --
Cut does not exist in the menus), like with the default bindings.
Instead simply say that no linter is defined.
This fixes https://savannah.gnu.org/bugs/?65204.
Bug existed since version 5.5, commit bc368133, but before
that commit nano would crash on an empty linter command.
Instead simply say that no formatter is defined.
This fixes https://savannah.gnu.org/bugs/?65196.
Bug existed since version 4.6, since the formatter was reintroduced.
On Windows builds, gnulib might set GETRANDOM_LIB to -lbcrypt and then
use that API. But since we don't include $(GETRANDOM_LIB) when linking,
we fail. On Linux systems, this is empty as getrandom APIs are part of
the main C library already. This is also what the link requirements say
in gnulib's modules/getrandom spec.
This avoids miscolorizing part of a string when it contains a URL.
This fixes https://savannah.gnu.org/bugs/?64340.
Reported-by: Yonut Smith <deanlast3@gmail.com>
Problem has existed for more than twenty years, at least since support
for multine-line regexes was added in commit 6c1e6612 in 2002.
The terminal in VSCode splits pastes into 50-byte chunks and can
thus split an escape sequence somewhere in the middle, resulting
in nano failing to recognize the end-of-bracketed-paste sequence
and thus hanging -- until another, different-sized paste is made.
Avoid this hang by interpreting any invalid escape sequence that
starts with "\e [ 2" as a truncated end-of-bracketed-paste.
(This will leave a spurious tilde after the 39-character paste,
which is not nice but... better than hanging.)
This works around https://savannah.gnu.org/bugs/?64996.
Reported-by: Jacob Lifshay <programmerjake@gmail.com>
Even though in nano the names F13 to F24 exist, these names actually
refer to Shift+F1...Shift+F12. One cannot blame people for thinking
that F13 in nano is the same as F13 in Xorg, so... recognize the escape
sequence for the latter and map it to what nano calls F13.
This accommodates users that put F13...F16 in a custom keymap for Xorg.
This fixes https://savannah.gnu.org/bugs/?64632.
Reported-by: Danny Milosavljevic <dannym@scratchpost.org>
Problem existed since version 5.0, commit 9a6158cd.
When softwrapping at blanks, the wrapping routine should, when called
again, continue searching from where the previous chunk ended, not from
the point it reached during that previous search, because this could be
*just* beyond the space that could be the next breaking point.
This fixes https://savannah.gnu.org/bugs/?64945.
Reported-by: Andreas Schamanek <schamane@fam.tuwien.ac.at>
Bug existed since version 6.4, commit 0e9bef34.
Benno Schulenberg