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.
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.
When the user hits the M-C toggle while option --zero is in effect,
instead of complaining "Not possible", do what the user probably
tries to achieve: cancel `zero` mode and switch on `constantshow`.
This makes nano more usable for users that are accustomed to the
near universal use of ^F for Find/Search in other programs, and
especially for users that somehow access a terminal through their
browser (where ^W will, destructively, close the terminal tab).
(To keep the bindings consistent, make ^B start a backward search,
and let M-F and M-B search for the next occurrence in the matching
direction.)
Suggested-by: Chris Allegretta <chrisa@asty.org>
Suggested-by: Donnie Ferris <DonnyBahama@gmx.com>
https://lists.gnu.org/archive/html/nano-devel/2023-01/msg00001.html
This makes nano more usable for users that are accustomed to the
near universal use of ^F for Find/Search in other programs.
To keep the bindings consistent, make ^B start a backward search,
and let M-F and M-B search for the next occurrence in the matching
direction.
At least some of the VTE-based terminals claim to be compatible with
xterm-25color (and set TERM to that value). But they really aren't:
they mishandle the focus-in and focus-out events, for example. So,
catch and discard the corresponding keycodes that nano shouldn't be
seeing at all.
This improves the fix for https://savannah.gnu.org/bugs/?64578.
When the red, green and blue components of a three-digit hex #RGB code
are equal and they aren't #000 for black or #FFF for white, map them to
xterm-256color's 24-level grayscale ranging from index 232 to 255.
This means that the 14 gray levels available in #RGB codes all map to
different tones, whereas previously they mapped to only the four gray
tones available in the 6x6x6 color cube.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
Xfce Terminal sets TERM to xterm-256color even though it does not have
all the capabilities that an xterm has, leading it to misinterpret some
escape sequence and produce a spurious 0x24C key code.
Intercept this mistaken key code and tell the user what is wrong.
This mitigates https://savannah.gnu.org/bugs/?64578.
Reported-by: Lawrence R. Steeger
An ambiguous option like --back or --word would cause nano to spew
the entire help text. It should do the latter only when the user
explicitly requests it.
The short option '-?' was removed nine years ago in commit 43019189,
then restored six years later in 5bd92d4c, and then removed again two
months later in 743100fe due to getopt() returning '?' for options
that aren't recognized, preventing the use of '-?' as a valid option.
However, getopt() provides a way to check for unrecognized options
via the 'optopt' variable, which gets set only for invalid options.
Signed-off-by: Mateusz Kazimierczuk <mataha+savannah@protonmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
When the directory that the user is browsing in is deleted by another
process at the moment that nano is building the list of file names,
this can result in an empty list, which some items in the main loop
in browse() cannot handle. Prevent this mishandling by not entering
the loop when the list is empty.
This fixes https://savannah.gnu.org/bugs/?64465.
Reported-by: Jerry Meng <jerrytstng@gmail.com>
Speller, linter, formatter, and execute-a-command cannot be used in
restricted mode, but the relevant keys should report that the function
is *disabled*, not that the key is unbound.
This fixes https://savannah.gnu.org/bugs/?64226.
Problem existed since version 3.2, since nano reads the nanorc files
also in restricted mode.
This suppression prevents the filename flashing by at the bottom
of the screen when switching between buffers.
This addresses https://savannah.gnu.org/bugs/?64019
Reported-by: Alan Cristhian Ruiz <alancristhian@protonmail.com>
Problem existed since version 6.0, since --zero was introduced.
Various tools will output filenames with line numbers in the format
<filename>:<line>:<column>. Support this format in addition to the
+<line>,<column> format when opening files.
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The isxxxxx() functions expect their parameter to be either EOF or
a value in the unsigned char range. Passing a negative char value
could (in theory) result in unexpected behavior.
In view mode it should be impossible to modify any buffer, but...
when (through some bug) the user did succeed in modifying a buffer,
this should not lead to writing out this modified buffer to disk.
Had this safety stop been present earlier, it would have prevented
the second part of https://savannah.gnu.org/bugs/?63616.
A string bind can only contain bytes (chars), not keycodes (integers,
in nano upto 0x4FF). So, apart from an error code or a placeholder
command code, get_code_from_plantation() can only return a byte.
The function get_code_from_plantation() should return ERR only when
the string bind is fully exhausted. In the normal case, where some
bytes are still available, it should return the first of these bytes,
so that the {verbatim} function will work too.
This fixes https://savannah.gnu.org/bugs/?63702.
Bug existed since version 7.0, commit 958ec294,
since command cartouches were introduced.
This separation avoids the impression that we're thanking the mentioned
people for their use of nano (something they probably don't do).
(Also, remove two other blank lines -- effectively moving these two
lines further up, keeping the total amount of whitespace the same.)
When in view mode, nothing shouldbe allowed to be entered into
(or deleted from) the buffer.
This fixes https://savannah.gnu.org/bugs/?63616.
Reported-by: Timothy Liu <liuxf19@163.com>
Bug existed since version 4.8, commit 0e6d693d.
That is: do not silently return from parse_one_include() when the
given file does not exist, *and* return the filename (or pattern)
itself when it matches nothing.
This fixes https://savannah.gnu.org/bugs/?63446.
Bug existed since version 4.0, commit d3f0d32e.
This prevents an unwanted message when nano
is compiled with -fsanitize=undefined.
This fixes https://savannah.gnu.org/bugs/?63447.
Problem existed since version 4.8, commit 343f97b3,
since the --rcfile option was added.
Make sure that there is only whitespace to the left of the cursor
before setting 'allblanks' to TRUE, because this latter value will
cause these characters to be eaten (as a special case, to avoid
creating lines that contain only blanks when both --autoindent
and --breaklonglines are on).
This fixes https://savannah.gnu.org/bugs/?63407.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug existed since version 2.9.8, commit d00ab406.
This places the cursor in a more predictable position.
This fixes https://savannah.gnu.org/bugs/?63223.
Issue existed since version 4.4, commit a9dd73fb,
since the +/string feature was introduced.
Not just for +/ (a search command without a string) should nano report
an "Empty search string", but also for +c/ or +r/ or similar.
This fixes https://savannah.gnu.org/bugs/?63222.
Bug existed since version 4.4, commit 2326bf69.
When the user interrupts an external command that hangs or takes too
long, nano should also kill the data-sending process (when present).
This fixes https://savannah.gnu.org/bugs/?63177.
Bug existed in this form since version 4.3, commit d946f38a,
but basically existed since version 3.0, commit ec339d3b.
When something goes wrong while executing an external command or while
piping text to it, report an error on the status bar and restore the
state of the buffer to what it was before the execution.
This fixes https://savannah.gnu.org/bugs/?63114.
Bug existed since version 2.9.8, since filtering text was introduced,
but basically existed since before version 2.0.0, since executing an
external command was introduced.
The execute_command() function — then called open_pipe() — was changed
to have a boolean return value in commit ce62e82a eighteen years ago,
but the value has never been used or checked.
The function line_from_number() can handle only line numbers that exist,
and will crash otherwise. (The lack of checks makes the function fast.)
This fixes https://savannah.gnu.org/bugs/?63120.
Bug existed since commit d1e28417 from five weeks ago.
Since commit c848ec3d from three years ago, nano has assumed that
'char' is always a single byte. So... elide the last occurrences
of sizeof(char), as they give a false impression of generality.
The function recode_LF_to_NUL() has to iterate over the string anyway
(to replace each \n with \0), so... instead of calling strlen() right
before it, just let recode_LF_to_NUL() return the length of the string.
(This is not speed-critical code, but... it saves one iteration over
the entire buffer contents whenever writing out a file.)
(There is no need to recode the NULs back to LFs because the sending of
the data happens in a separate process, which then simply disappears.)
This fixes https://savannah.gnu.org/bugs/?63106.
Bug existed since version 2.9.8, since filtering a buffer or a region
through an external command was introduced.
Not quitting would make nano hang for several seconds (which is very
annoying) and then die and save an emergency file (which is useless).
This fixes https://savannah.gnu.org/bugs/?63109.
Bug existed chiefly since version 5.9, commit 8d1a666d,
but basically existed since before version 2.0.0.
Analogous to commit 3922b531: instead of allocating and later freeing
a tiny fragment of memory for every character that the user enters (in
the edit window or at a prompt), reserve a small piece in the beginning
and retain it, and increase (but never decrease) its size as needed.
This addresses the second part of https://savannah.gnu.org/bugs/?63086.
In theory, the 'size_t' of 'capacity' could be just two bytes, which
means the keystroke buffer would overflow for pastes that are larger
than 32 kilobytes -- which are unlikely to occur, but... possible.
However, previously there was *no* overflow check when extending the
keystroke buffer (only when trying to put back a key code), so this
check is an improvement.
(On a regular machine, 'size_t' is at least four bytes, which means
the keystroke buffer would overflow at 2 gigabytes. Such a paste
is extremely unlikely to occur, so this check is really a no-op.)
Instead of allocating and freeing a tiny fragment of memory for every
keystroke, reserve a small piece in the beginning and then retain it,
because it will be needed again and again and again. Increase the size
when needed (for a large paste, probably), but don't bother to shrink
it afterward.
This addresses the first part of https://savannah.gnu.org/bugs/?63086.
Move the triggering of the line redraw out of the error path, and
into a better place: next to the normal clearing of the feedback.
This fixes https://savannah.gnu.org/bugs/?63053.
Bug existed since version 6.0, commit 6d828cf4.
As the magic line isn't really a line (it is not counted in the number
of lines read and written), and nothing is on it (not even a newline),
it doesn't make sense to allow any regex, like ^ or $, to match it.
This fixes https://savannah.gnu.org/bugs/?63034.
Indirectly-reported-by: Mike Scalora <mike@scalora.org>
Bug existed since before version 2.0.0.
Calling strstrwrapper() with the Backwards, Casesens, and Regex flags
unset is equivalent to calling mbstrcasestr(). So... do that instead
and quit saving and restoring the flags for each call of findfile().
This saving-and-restoring has been redundant since commit b0957254
from eight years ago.
The dots gave the impression that the next keystroke (hex digit) would
land somewhere on the dots. But this is not so -- the current digits
are instead shifted to the left and the new digit is added at the end.
Also adjust and improve several comments.
Also elide three calls of tolower(), using ORing with 0x20 instead,
as we're dealing with plain ASCII here.
Rename a variable too, away from a double abbreviation.
Instead of requiring always six digits, allow the user to indicate
with <Enter> or <Space> that the digits typed so far are the complete
Unicode code point (when prefixed with the missing number of zeroes).
This fulfills https://savannah.gnu.org/bugs/?63021.
Inspired-by: the <Ctrl+Shift+U> shortcut that some desktops have
This does not quite do what I would have liked (scroll only when needed)
when on a softwrapped line and jumping to a different chunk, but... it's
still better than needlessly centering the line.
(The user can still center the line, if that is what they want, by using
a period or a slash instead of a comma.)
This addresses https://savannah.gnu.org/bugs/?63008.
Nobody will configure nano with --enable-tiny --enable-extra, but *if*
someone does, the title bar should be absent during the crawl.
Also, swap two messages, so that their order in the POT file will be
more sensible -- a closing brace comes after the function name.
"Cannot map name %s to <thing>..." was unnecessarily verbose and vague.
I have kept these strings unchanged all these years because I didn't
want to invalidate the existing translations. But now it's time to
harmonize things and simply say "Unknown <thing>: %s" for an invalid
function name, menu name, option name, and syntax name.
("No such <thing>: %s" is nice and snappy, but its translations often
are clumsy and longer and unclear.)
(It is a harmless leak, but LeakSanitizer is loud when it complains.)
After having determined that there is a menu name, first check that
it is valid, before processing the string or the function name.
This fixes https://savannah.gnu.org/bugs/?62991.
Problem existed since version 2.9.4, since string binds were introduced.
This makes more sense than letting the formatter and the linter depend
on ENABLE_COLOR (which maybe should have been named ENABLE_SYNTAX).
This fulfills https://savannah.gnu.org/bugs/?50080.
Six years ago, commit a878f5f1 introduced a call of regenerate_screen()
directly in the input routine, which made the call of refresh_func() in
the prompt routine redundant -- except when in the file browser.
Since version 6.0, with option --zero, the edit window can cover
the whole terminal. Make use of this also for the credits crawl.
Also, shorten and quicken the crawl a bit, and make it start always
on the bottom row, instead of (for mysterious reasons) one row higher
when the terminal has an odd number of rows.
Furthermore, don't put back the key the user typed to stop the crawl.
Instead of starting always from the top of the buffer, start at the
current line, as it is quite likely to be near the target line.
(Since the previous commit we're assuming that openfile->current is
always valid, so we might as well make use of this assumption.)
Also, rename a parameter to make its meaning more explicit.
After undoing an <Enter> or redoing a line join, it is likely that the
"eaten" and freed line was the current line. In fact, goto_line_posx()
should not refer to it any more, but... accommodate for this and just
set openfile->current to a valid value before calling goto_line_posx().
This fixes https://savannah.gnu.org/bugs/?62952.
Bug existed since version 6.3, commit eea3e1f0.
Checking for the literal ^N, ^Q, and ^Y before checking for do_toggle
and full_refresh made it impossible to rebind any of those keystrokes
to these two functions. (Not that anyone would want this, but...)
Problem existed since version 4.3, commits 341601e1 and 82aea04c.
This allows specifying bindable functions in a string bind by name
instead of by the literal control code or escape sequence to which
they are bound, which makes for a much more readable string bind,
and also allows specifying functions that are not bound to any key.
The opening brace, {, is made into a special symbol inside a string
bind, and each literal occurrence there needs to be escaped as {{}.
This fulfills https://savannah.gnu.org/bugs/?61692.
Requested-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
https://lists.gnu.org/archive/html/nano-devel/2018-02/msg00006.html
This makes that the three options that change the default layout
of the interface (--stateflags, --minibar, --zero) come last.
Also, sort the option letters into a consistent order in the code.
(That 'also_the_last' now gets reset to FALSE whenever the cursor moves
to a different line is fine -- it is redundant when the mark is off, but
it does no harm.)
It was silly to check again specifically for <Del> and <Bsp> after
any possible keystroke had been handled. It was an anomaly.
This makes the tail of do_deletion() similar to the tail of inject().
(That sometimes the current line is redrawn twice is acceptable -- how
often does one type <Backspace> while having Shift-selected something?
Normally one wouldn't, because it would cancel the selection, so it's
fine to accept some inefficiency for this case.)
The checking for all functions that are marked as not-okay-for-view-mode
was excessive and unneeded. It had been inherited from commit d47d8cd4
from thirteen years ago, and was never verified for correctness.
This addresses the main part of https://savannah.gnu.org/bugs/?62903.
The linter has been marked as NOVIEW since it was introduced in 2.3.3.
But that was a mistake, as the tool does not change the buffer contents.
This addresses a minor part of https://savannah.gnu.org/bugs/?62903.
