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.
Normally, when recording a macro, users will make their keystrokes
slowly and carefully, and will most likely wait to see the effect
of the previous keystroke before making the next. So, the chances
of two `recordmacro` keystrokes coming in in quick succession is
normally nil. The 'macro_length' variable just needs a guard to
prevent it from underflowing when someone is hammering the keys.
This fixes https://savannah.gnu.org/bugs/?65394 in a better way.
When the justified region fits in its entirety onscreen, then it should
be shown in its entirety, because the user is probably curious what the
region looks like after justification. This behavior will mean that
the line above the topline of the screen will still have multidata
(when the syntax has multiline regexes). When the justified region
does not fit onscreen, then as much as possible should be shown --
meaning that the cursor should be either at the top or the bottom
of the viewport, meaning that it should not be centered.
This fixes https://savannah.gnu.org/bugs/?65482.
The issue was reported by `correctmost`.
Bug existed since version 4.0, since justifying a region was introduced.
When justifying a region that was marked backwards, the cursor
should stay at the beginning of this region. The old logic was
faulty because mark_is_before_cursor() does not give the correct
result *after* the justification has been done: for some reason
the mark ends up always before the cursor.
Bug existed since version 5.2, commit 0f8423eb,
which mistakenly removed the auxiliary variable. :/
The strings are gettextized further down, for the non-tiny version,
so they will get translated anyhow. The relevant translator hint
is the earlier one about "the next thirteen strings".
Also adjust an indentation, and ungettextize another string for
consistency.
With NetBSD curses, when only the cursor is moved (without writing any
text), then a call of wnoutrefresh() is needed to make doupdate() move
the cursor. Ncurses does not need this.
This addresses https://savannah.gnu.org/patch/?10438.
The calls of wnoutrefresh() after those new blank lines are not needed
for ncurses to show the cursor in the right place, but are logically
needed because things have been written to the screen in the preceding
code -- although nano seems to work correctly also without those calls.
A detailed list of changes is useful for a small number of users only,
and only when the changes are fairly recent.
The NEWS file, that contains a summary of user-visible changes and
will be useful for a larger number of users, is distributed in full.
This looks better in the help viewer (^F/^B matching the pair M-B/M-F),
and showing ^F instead of ^W for search in the main edit window will
prevent novice users from using ^W in situations where they shouldn't.
As a backward search is now normally always bound (to ^B, instead of
conditionally to ^Q), ^L should always be shown in the help viewer.
This fixes https://savannah.gnu.org/bugs/?65434.
Problem existed since commit 8a304bdf, since ^F/^B do a search.
When modern bindings are requested, ^S should save and ^Q must exit,
so --preserve and 'set preserve' need to be cancelled.
This fixes https://savannah.gnu.org/bugs/?65433.
Bug existed since commit 18b37c98, which introduced --modernbindings.
Because meanwhile the cursor might be someplace where EOF is offscreen.
This effectively reverts commit 9ccf85ea from two years ago, but also
sets 'focusing' to false so that the last line of the buffer will be at
the bottom of the edit window, where it probably was when Bsp was typed.
This fixes https://savannah.gnu.org/bugs/?65428.
The issue was reported by `correctmost`.
Bug existed since version 6.3, commit 9ccf85ea.
When a justification (or even a spell check) is undone or redone,
this might affect the matching of multiline regexes, so... schedule
a recalculation of the multidata in those cases.
This fixes https://savannah.gnu.org/bugs/?65426.
The issue was reported by `correctmost`.
Problem existed since version 6.3, commit 80c2000f.
Since commits c8363a0d and a75bf0a1 from seven years ago, the Execute
menu permits retrieving previously executed commands, but the help text
and help lines never showed the corresponding keystrokes.
Four years ago commit d3954901 made the Execute menu directly accessible,
but I preferred to not mention the ^P/^N keystrokes in the help lines,
to leave as much space as possible for the executable functions (added
in subsequent commits), thinking that no one would want to rebind those
keystrokes anyway, as the Up/Down arrows seem more logical and easier.
The issue was reported by Ivan Vorontsov:
https://lists.gnu.org/archive/html/help-nano/2024-02/msg00003.html
Benno Schulenberg