Since commit 50954a4b from two years ago, a replacing session will
not ever change the final empty line, and thus a fresh magic line
will never need to be undone or redone.
This complements commit c6a26641 from five months ago.
Most calls of draw_all_subwindows() are made while in the edit window.
The only call that could occur while in the file browser is the one in
regenerate_screen(). So only this call needs to be guarded against
being made while the file list is being shown.
This can be useful when replacing text in a Japanese locale,
avoiding the need to guide the input method to produce "A".
Inspired-by: Takeshi Hamasaki <hmatrjp@users.sourceforge.jp>
When the mark is on, moving the cursor to the top or bottom row should
highlight the relevant area -- thus requiring a call of edit_refresh()
to be scheduled.
Also, drop two calls of place_the_cursor(), as that is done anyhow in
the main loop, either directly, or indirectly through edit_refresh().
This fixes https://savannah.gnu.org/bugs/?65992.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug existed since version 8.0, since Alt+Home/Alt+End were introduced.
Instead of simply overwriting the current contents of the keystroke
buffer with the contents of the macro buffer, insert the latter's
contents at the head of the keystroke buffer.
This allows using {runmacro} in a string bind, and allows typing ahead
over a laggy connection after invoking `runmacro` (normally with M-;).
This fixes https://savannah.gnu.org/bugs/?65991.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug exists since version 2.9.4, since string binds were introduced.
When NumLock is off, let Ctrl plus the central key on the numeric keypad
center the current line.
(This binding is not advertised anywhere
-- it's left as a little Easter egg.)
Something similar can be achieved with:
bind ^T "{center}{bottomrow}{center}{toprow}" main
bind ^B "{center}{toprow}{center}{bottomrow}" main
But that requires allocating two extra shortcuts, and it works right only
when the edit window has an odd number of rows, not with an even number.
Also, this new ^L behavior is available by default, out-of-the-box.
On the first call, `cycle` centers the line with the cursor, on the
second consecutive call it pushes that line to the top of the viewport,
and on the third consecutive call to the bottom of the viewport.
The function do_tab() is only ever called when in the main edit window,
and never called while a bracketed paste is in progress.
(The two conditions were thoughtlessly copied when this fragment of code
was moved here three commits ago.)
When softwrapping with a tabsize larger than the width of the viewport,
scrolling one row when the cursor goes offscreen might not be enough,
so in that case use edit_redraw() instead.
This fixes https://savannah.gnu.org/bugs/?65860.
Bug existed since version 2.9.6, commit 0d9080a2.
This allows a {tab} in a string bind to indent a marked region.
This fixes https://savannah.gnu.org/bugs/?65859.
Problem existed since version 7.0, since braced function names
were introduced.
Activating --modernbindings when the binary's name starts with "e"
interferes with Debian's alternatives system that symlinks `editor`
to `nano` in a default install.
(Also: why "e"? It would have made more sense to check for "m",
similar to the checking for "r" for a restricted nano.)
This reverts commit 580eaf29 from fifteen months ago.
This addresses https://savannah.gnu.org/bugs/?65810.
Reported-by: Colin Snover <nano@zetafleet.com>
Prevent also the toggling of Append and Prepend. All four functions
should not be available in restricted mode, and are absent from the
WriteOut menu in that mode, but using {browser}, {backup}, {append}
or {prepend} in a string bind allowed to bypass the menu checks.
This fixes https://savannah.gnu.org/bugs/?65819.
Problem existed since version 7.0, since braced function names
were introduced.
Since version 3.2, commit 5ca444e5, nano reads the nanorc files also
in restricted mode (when not also --ignorercfiles is given), meaning
that syntaxes are available and that a specific syntax can be selected
on the command line. So, the --help output in restricted mode should
list the relevant option: -Y<name> / --syntax=<name>.
(This should have been part of commit b81995af from six years ago.)
The bindable function 'nowrap' has been deprecated for three years,
since version 5.5, commit e14127b8.
(The obsolete options --nowrap and 'set nowrap' continue to exist.)
When one has installed additional syntaxes, one tends to forget
what exactly is there. So it's nice to be able to list them.
The syntaxes are listed in the reverse order in which they were
read: the most recent first.
The long form of the option is, of course, --listsyntaxes,
which can be abbreviated to --list.
This fulfills https://savannah.gnu.org/bugs/?65779.
The feature was suggested by `davidhcefx`.
Stop doing colon parsing by default, to avoid surprises and frustration
for users that have filenames that end in a colon plus digits.
The equivalent rcfile option is, of course, 'set colonparsing'.
Using +1, or similar, before the filename disables any colon parsing
and the filename is taken as is.
Starting from the end of the provided filename avoids needlessly looking
at colons that are somewhere in the middle of the path or the filename.
It also avoids inconsistenly interpreting a specified line number as a
column number when the filename itself ends with a colon plus digits
and the filename without the colon plus digits exists too.
This also removes the eliding of a backslash before a colon, which
would mangle the filename if the name actually contained a backslash
followed by a colon.
Negative line and column numbers are no longer allowed when using the
colon notation.
This fixes https://savannah.gnu.org/bugs/?65781,
and fixes https://savannah.gnu.org/bugs/?65782.
Problems existed since version 8.0, since colon parsing was introduced.
While updating the screen, ncurses by default polls the input source
now and then to see if there is new input, and if so, stops updating
the screen and waits for the next call of doupdate() or refresh().
https://lists.gnu.org/archive/html/bug-ncurses/2024-05/msg00077.html
Disable this polling, as it is just a waste of time, and there *might*
be situations where the intruding keystroke does not actually trigger
a new update, which could result in a half-updated screen.
When the file 'foo:24' exists (but not 'foo') and the user wants to
use the colon notation to place the cursor on a certain line, then
nano would first interpret the given line number as a column number,
before noticing that 'foo' does not exist and then skipping the first
colon. So, when such a misinterpretation occurs, the column number
needs to be reset to zero.
When the user specifies, on the command line, a filename that ends with
a colon plus digits, and that filename exists in the file system, then
open that file, instead of interpreting the digits as a line number.
Also, if the filename stripped of the colon plus digits does not exist,
then do not interpret the digits as a line number either but treat them
as part of the file name.
Before this change, the user would have to escape the colon whenever
they wanted to open a file whose name ended with a colon plus digits.
Now the user needs to escape the colon only when 'foo' exists and they
want to create, say, 'foo:24'.
Problem-was-reported-by: Ralph Corderoy <ralph@inputplus.co.uk>
https://lists.gnu.org/archive/html/nano-devel/2024-05/msg00001.html
Mitigation-was-suggested-by: Mike Scalora <mike@scalora.org>
https://lists.gnu.org/archive/html/nano-devel/2024-05/msg00008.html
Nano does not recognize the urxvt escape sequences for other
<Alt+cursorkey> combinations either. And with the previous
two commits, the urxvt user can now "help themselves".
This reverts commit 363a4378 from three days ago.
This makes those keystrokes work too when --raw is used.
But more importantly: these raw sequences can be used in an
~/.Xresources file to override the odd behavior of urxvt for
those keystrokes, making the previous commit redundant.
When pressing Alt+Home/Alt+End on urxvt, urxvt either sets the high bit
of the last byte in the sequence for Home/End (when Meta8 is True), or
sends an extra escape before that same sequence (when Meta8 is False).
Accommodate for this bug by recognizing the produced code sequences.
Indirectly-reported-by: Sébastien Desreux <seb@h-k.fr>
https://lists.gnu.org/archive/html/nano-devel/2024-05/msg00007.html
The 'openfile->fmt' element gets initialized to 'UNSPECIFIED',
so the code has to take that possibility into account.
This fixes https://savannah.gnu.org/bugs/?65676.
Bug existed since version 8.0, commit fe4f74f6.
This closes a window of opportunity where the emergency file could be
replaced by a malicious symlink.
The issue was reported by `MartinJM` and `InvisibleMeerkat`.
Problem existed since version 2.2.0, commit 123110c5, when chmodding
and chowning of the emergency .save file was added.
When recording a macro over a laggy connection or on a slow, overloaded
computer, several keystrokes could be recorded in one burst, and if any
but the last of those keystrokes was the shortcut for `runmacro`, then
running the macro would lead to an infinite loop and nano would hang.
This new implementation of snipping the "last keystroke" will, however,
snip *too many* keystrokes when several of them were recorded at once
and `runmacro` or `recordmacro` was among them, resulting in a cropped
and thus misrecorded macro. But... that's better than hanging.
In general, though, the user should be slow and deliberate when
recording a macro: waiting for nano to have processed the last
keystroke before typing the next.
This fixes https://savannah.gnu.org/bugs/?65649.
The issue was reported by `correctmost`.
Problem existed since version 2.9.0, since macros were introduced.
These calls of do_delete() were meant to delete just one character,
but over time do_delete() morphed into doing also other things...
Change the calls to invoke the correct function instead.
(This also avoids snipping any zero-width characters that come after
a snipped space, as that is probably not what the user wants.)
This fixes https://savannah.gnu.org/bugs/?65636.
The issue was reported by `correctmost`.
Bug existed since version 3.2, commit ae3ec178,
when --zap was introduced.
Collin Funk