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.
Redoing an automatic hard-wrap while one or more chunks of the affected
line are offscreen, can leave 'firstcolumn' with a value that doesn't
fit the situation. So, make sure that it has a valid value.
This complements the previous commit.
This fixes https://savannah.gnu.org/bugs/?65611.
The issue was reported by `correctmost`.
Bug existed since version 2.8.6, commit e375995d.
When one or more chunks of the current line are above the viewport,
and this line gets hard-wrapped, then 'edittop' needs to be advanced,
otherwise the first row could be blank -- representing a chunk that
doesn't exist any more.
This fixes https://savannah.gnu.org/bugs/?65604.
The issue was reported by `correctmost`.
Bug existed since version 2.8.6, commit e375995d.
When opening a nonexistent file with nano, it likely consists of only a
name without any path component, and thus without any slash. So when a
file regex checks for a slash, it should check also for start-of-string.
This fixes https://savannah.gnu.org/bugs/?65591.
Problem existed for the Makefile since version 2.9.8, commit 22663f8a,
and for .profile since version 3.0, commit 4a268678 (but earlier, nano
did not recognize .profile files at all).
When an entirely blank line is trimmed (when --autoindent is active and
Enter is pressed while the cursor is at the end of the current indent),
the mark needs be adjusted *before* 'current_x' is zeroed, otherwise the
mark gets moved too much to the right, which causes the region to become
bigger than what the user intended, or leads to accessing unallocated
memory.
This fixes https://savannah.gnu.org/bugs/?65586.
The issue was reported by `correctmost`.
Bug existed since version 2.8.1, commit 005ee8ed.
A "Read xx lines (converted from...)" message should be suppressed when
--zero or --minibar are active (just like the normal "Read xx lines"),
as otherwise it gets shown at a confusing moment when multiple files
are opened at the same time. The message should get shown, however,
when inserting a file into the current buffer.
This fixes https://savannah.gnu.org/bugs/?65560.
Bug existed since version 6.0, commit f147131e.
The idea of the warning was that `row < 0 || row >= editwinrows` would
never be true: that the check was redundant and could be removed.
As it appears to be too hard to make sure in advance that a chunk will
not fall outside the viewport, just drop the warning and leave the check
in place.
This also addresses https://savannah.gnu.org/bugs/?64168.
Reported-by: Matteo Raso <matteo_luigi_raso@protonmail.com>
When we're on the last row in the viewport, it is unwise to try and draw
the next line.
This fixes https://savannah.gnu.org/bugs/?65539.
The issue was reported by `correctmost`.
Bug existed since commit c2322f85 from three days ago.
Drawing a line will allocate multidata for it (even when the line is
actually empty), so that this multidata will not be missing later on
when the next line gets drawn in the same burst of keystrokes.
(This also removes the triggering of a full refresh when line numbers
are active: only the new magic line needs to be additionally drawn, in
order to get the line number printed.)
This fixes https://savannah.gnu.org/bugs/?65516.
The issue was reported by `correctmost`.
Problem existed since version 6.3, commit 80c2000f.
It is bindable only in the Insert menu -- in the Execute menu it has
a "blind", unadvertised binding (because I consider toggling between
menus somewhat of a misfeature).
On my current laptop, typing <Alt+Insert> is awkward because it requires
holding down <Fn> too. Also, M-" and M-' are in the normal symbols area
of the keyboard, which makes them easier to type and more discoverable.
Furthermore, being next to M-: and M-; (on a US keyboard) reinforces the
meanings: start/place, stop/remove, run/goto.
