Also, mention my email address in the colophon of the PDF,
to avoid the impression that Chris is the sole responsible.
And improve the general layout by adding three blank lines.
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.
As double-quote-plus-space indicates the end of a regular expression
in a nanorc file, the inclusion of this combination *in* a regular
expression requires breaking the juxtaposition of the two, which
can be achieved by putting either of them between square brackets.
(It can also be achieved by preceding the space with a backslash,
which is shorter, but... the above method is more symmetrical.)
This addresses https://savannah.gnu.org/bugs/?62997.
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.
