Avoiding this leak is more trouble than it's worth: invocation_error()
will be called seldomly, and when it is called, the user will probably
quickly exit from nano to fix things.
Also declare the speller functions as const again, so they don't give
the impression that their result can be freed.
Suggested-by: Brand Huntsman <alpha@qzx.com>
Now you can have a look elsewhere in the buffer (and even delete
or paste stuff there) and when you return to the original line
and continue typing, any spillover from automatic hard-wrapping
will spill over onto the same line it spilled over to before.
You can even switch to a different buffer and return and continue
typing, and stuff will still spill over to the same line.
In the bargain, this gets rid of a bit of flag-resetting code
that was run for many keystrokes, in most cases needlessly.
This addresses https://savannah.gnu.org/bugs/?56189.
Most of the returned error messages are fixed strings, not allocated
strings.
This fixes https://savannah.gnu.org/bugs/?56188.
Reported-by: Aliaksei Sakovets <alexeysakovets@gmail.com>
Bug existed since version 4.1, commit f645009a.
When automatic hard-wrapping causes some piece of a line to be pushed
to the next line, then a separating space needs to be added at the tail
of this piece only when this piece actually gets prepended.
This fixes https://savannah.gnu.org/bugs/?56185.
Bug existed since version 2.9.2, commit 29f7654a.
When typing a space causes both the succeeding word and the cursor to
be pushed to the next line, then this space (and any contiguous ones)
does need to be snipped (when --trimblanks is in effect).
This fixes https://savannah.gnu.org/bugs/?56180.
Bug existed since version 2.9.3, commit 91073be4.
Fuzzy strings don't contribute anything to the translations that the
users get to see. They are useful only for translators, but translators
fetch or receive their PO files from the TP. For nano, fuzzy strings
just bloat the distribution tarball.
These obsolete strings contribute nothing to the translations that the
users get to see. They are somewhat useful only for translators. But
as nano is registered at the Translation Project, translators fetch or
receive their PO file from there (or they keep their own archive), so
these obsolete strings are not getting lost. But for nano, they just
burden the distribution tarball.
Do the same as in the previous commit: re-evaluate the start of the
viewport when lines that are located above this viewport may have
changed. This is relevant when softwrap is on.
When only the trailing chunk of a line is displayed on the top row of
the screen, and the unindenting of this line leads to a reduction in
the number of chunks, then the starting point of the viewport needs
to be re-evaluated. For simplicity, do this always when something is
unindented.
This fixes https://savannah.gnu.org/bugs/?56102.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since around version 2.9.2.
All other options are off by default and can only be switched *on*
(either by a command-line option or a nanorc setting) -- there are
no command-line options to switch them off again. Except for the
--breaklonglines/--nowrap pair. So these need special handling.
This fixes https://savannah.gnu.org/bugs/?56119.
Reported-by: Sébastien Desreux <seb@h-k.fr>
Bug existed since version 4.0, commit 4d40bea5.
When the file starts with one or more blank lines, the first paragraph
doesn't start on line 1.
This fixes https://savannah.gnu.org/bugs/?56117.
Bug existed since version 4.0, commit ac8bd2a2.
It is still possible to use --jumpyscrolling on the command line or
'set jumpyscrolling' in a nanorc file, but a user will have to restart
nano when they decide they want chunky instead of smooth scrolling,
a decision that should be rather rare.
This frees up the M-S keystroke to be reused for toggling softwrap.
The error messages from gnulib need to be included into nano's POT file
so that those messages get translated when nano is built on a platform
where the modules that contain the messages get used.
This fixes https://savannah.gnu.org/bugs/?56107.
Bug existed since gnulib support was added in version 2.8.0.
The relevant modules were added by commits 3deec435 and 272345cc.
Benno Schulenberg