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.
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.
The double slash would derail the file browser, causing a crash.
This fixes https://savannah.gnu.org/bugs/?62760.
Reported-by: Frank Wolff
Bug existed since version 6.3, commit fdd946c0.
This has not been approved to be merged into master by any means but
I need to be able to track the status of my patch. So I'm starting
this branch and self hosted repository for myself.
Signed-off-by: rexy712 <rexy712@protonmail.com>
For some reason, when copying something to the system clipboard
with 'xsel', it wants to see all output descriptors closed before
it will exit without requiring ^C.
This fixes https://savannah.gnu.org/bugs/?62276.
Reported-by: Shi Yanling <sylphenix@126.com>
Bug existed since version 2.9.8, since piping text through an
external command was introduced.
Instead of silently opening an empty buffer when the user tries to
open a file in the current but disappeared directory, give a clear
warning about the absence of this directory.
This improves the fix for https://savannah.gnu.org/bugs/?62244.
When the working directory has been deleted from under nano's feet,
get_full_path() would move up in the directory tree until getcwd()
would succeed. This meant that a filename that was specified on the
command line without any path (or with a relative path) would refer
to a different file than what the user intended. Not good.
So, stop changing directories in get_full_path(). Use the realpath()
function with NULL as second parameter instead -- it has been part of
the POSIX standard since 2008, time enough for operating systems to
have caught up.
In the bargain, this saves seventy lines of complicated logic.
This fixes https://savannah.gnu.org/bugs/?62244.
Bug existed since version 2.0.0, commit 85e35e67.
Although an anchor at the top line is rather pointless, it shouldn't
get cleared when the user pipes just a part of the buffer through an
external command.
When the filter command makes just small, per-line changes, keeping the
cursor at the same line number allows the user to observe the effect of
the changes -- which is not possible when the cursor gets moved to the
end of the buffer.
This partially fulfills https://savannah.gnu.org/bugs/?57248.
When making a forward movement larger than a screenful, we cannot rely
on the multidata of the line before the new screen start to have been
set correctly by a previous screen drawing, so we need to recompute all
of the multidata, for the whole buffer, so that afterward we can freely
move around and draw the screen without having to do any backtracking.
Also when a piece of text larger than a screenful is pasted or inserted,
all the multidata needs to be recomputed.
This fixes https://savannah.gnu.org/bugs/?60041,
and fixes https://savannah.gnu.org/bugs/?62056.
First bug existed in this form since version 2.4.2, commit d49c267f
(but editing Python was incomparably slower in those days).
Second bug existed since version 5.6, commit 43d94692.
This mitigates https://savannah.gnu.org/bugs/?36864.
Reported-by: Clarence Risher <sparr0@gmail.com>
Problem has existed since the beginning, as nano empties the existing
file before writing the current buffer contents into it.
Fix building with x86_64-w64-mingw32 to cross-compile native Windows
programs. Need to:
* add checks for missing functions
* don't use signals that are unavailable on the platform
* avoid useless non-Linux sys/ioctl.h include
* use putenv instead of setenv as the latter is unavailable
When the user exits with ^X and gets warned that the file on disk
has changed, then typing ^C at the question whether to continue
saving should not discard the buffer and exit, but should return
the user to the filename prompt.
This fixes https://savannah.gnu.org/bugs/?61883.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug existed since version 2.9.0, commit 217cfbf3.
For consistency of style, the number of lines read should only be shown
when inserting a file into the current buffer, not when reading it into
a new buffer.
This amends the fix for https://savannah.gnu.org/bugs/?61509.
Inserting another file is somewhat unusual -- it's better to give
feedback about it.
This fixes https://savannah.gnu.org/bugs/?61509.
Bug existed since version 5.5, since the minibar was introduced.
When <Tab> at a prompt shows a list of filenames, this list should
not "sit" on the prompt bar but float one row above it.
This addresses the third issue mentioned in commit 03637030.
With --zero or 'set zero', nano will hide the title bar or the minibar
(whichever is active) and will use all rows of the terminal for showing
the text of the buffer. Only when there is an important message will
it be shown on the bottom row -- until the next keystroke.
This feature can be toggled with M-Z.
The feedback at startup ("Read nnn lines") is suppressed with --zero,
because it disrupts the fullscreen experience (and is hardly useful).
The "Reading..." message then needs to be suppressed too, otherwise
it creates an annoying little flash.
There are still some issues that need to be addressed:
* In the browser, when the highlighted item is on the bottom row, it
will get obscured by the prompt bar or the "Search Wrapped" message.
* In the edit window, when the search occurrence is on the bottom row,
it can get obscured by the "This is the only occurrence" message.
* When tabbing at a prompt shows possible completions, they are shown
a row too low.
