When opening multiple files, and the first of them has a lock file,
and the user chooses to not open the corresponding file, then nano
should NOT create an empty buffer in its stead.
This fixes https://savannah.gnu.org/bugs/?57777.
Bug existed since lock files were introduced, in version 2.4.0,
specifically since commit 6948d2e7.
When at startup the user presses Cancel at the "open anyway?" prompt,
cancel the whole startup: quit. But when the user answers No, just
skip the file and continue starting up.
Don't bother looping until the 1024 bytes are read. Writing the lock
file takes just one shot too, and that is more important to get right.
Also, correct the type for the result of read(), so that -1 doesn't
get turned into a positive number, which would mean that any error
would get ignored.
It would be better if nano wrote the full filename into the lock file,
because that would be clearer when Vim displays its warning, but...
this is faster and will do for now.
(Nano should simply also store the full filename in the openfile struct,
so that get_full_path() needs to be called just once for each file.)
This addresses https://savannah.gnu.org/bugs/?57713.
The call of ferror() as parameter of a %s specifier was a mistake --
it returns a number, not a string. Avoid the problem by combining
two error checks.
The man page of fwrite() does not say anything about errno, but I guess
that the function calls write() and that the possible error numbers of
that function apply.
In theory it is now possible that fclose() fails and returns an error
that then masks an earlier error of fwrite(). But I can't be bothered:
lock files are not essential, and any errors that might occur are most
likely overlooked anyway because they are not displayed in red.
This fixes https://savannah.gnu.org/bugs/?57724.
Bug existed since lock files were introduced, in version 2.3.2,
commit bf88d27a.
All the things that we need are located within the first 68 bytes of
the .swp file. We do write byte 1007 when the file is modified, but
we never reference it. We always wrote just 1024 bytes to the .swp
file, so it makes no sense to read in any more than that.
(Vim writes 4096 bytes to a .swp at first, before adding undo stuff
four seconds later. But the 1024 bytes appear to be enough for Vim
to recognize it as a lock file.)
When asking "continue?", I always thought that answering No would mean
that nano would not continue, that it would stop, that it would abort.
But No only means that it will not open the relevant file but continues
anyway to start up. Asking "open anyway?" is more easily understood in
that way.
Unreadable or corrupt lock files are not a user error nor user intent,
so they should not keep the user from editing the corresponding file.
Also, combine some error conditions to compact the code.
This addresses https://savannah.gnu.org/bugs/?57700.
When in view mode, the file cannot be edited, so there is no need to
warn anyone (through a lock file) that the file might soon change.
This fixes https://savannah.gnu.org/bugs/?57694.
(The ideal behavior would be that nano would warn the user beforehand,
before the file that is being edited by someone else gets overwritten,
but that would require many more changes. So... just give a helpful
warning -- that's already better than it was.)
(When the new or changed name is that of an existing file AND this
file is being edited by some other editor (or nano itself), then the
behavior is rather strange: nano asks whether to continue, but the
file has already been overwritten and there is nothing the user can
do to cancel or revert things. A later commit should improve this.)
This fixes https://savannah.gnu.org/bugs/?47975,
and fixes https://savannah.gnu.org/bugs/?53883.
When we switch to another buffer, the window may have been resized
since we were last in this buffer, so make sure that 'firstcolumn'
gets a fitting value.
This fixes https://savannah.gnu.org/bugs/?56991.
Bug existed since version 2.8.0, since the softwrap overhaul.
After the previous change, all remaining calls of parse_mbchar() have
NULL as their third parameter. So, drop that parameter and remove the
chunk of code that handles it. Also rename the function, as there are
already too many functions that start with "parse".
This case is caught (by O_EXCL) later on, at the appropriate moment:
when the file is created.
Also, this removes a superfluous lstat() for each temporary file.
Weird bug. The first occurrence is probably never hit because the
existing file has been tentatively opened fourteen lines earlier,
but that looks superfluous: double work. And the second occurrence
will not be hit because the temp file is unlikely to have disappeared.
Also, don't bother assigning the stream pointer of the existing file
to variable 'f', as it gets overwritten right away by the pointer of
the temp file.
A possible change in filename won't be pushed to the screen until a
doupdate() is done, and that won't happen until nano is waiting for
a keystroke again. So... just let it be.
The command can be used to run some kind of formatter or corrector or
arranging tool on the buffer. By default the command is bound to M-F.
The formatter/corrector/arranging program must be non-interactive.
This addresses https://savannah.gnu.org/bugs/?55365,
and addresses https://savannah.gnu.org/bugs/?54651.
For the three operations (justification, spell checking, and filtering)
that need to undo or redo two suboperations (cutting and then pasting)
in one go, pass the message that describes the operation to add_undo(),
so that the undo item does not need to be modified after the call.
This looks better, but does add some twenty NULL parameters elsewhere.
The extra things that close_buffer() did are only needed and useful
when manually closing a buffer, so move them there. The other three
calls of close_buffer() only need to get rid of the current buffer
(making the preceding buffer the new current one) and nothing else.
When after reading a file we are not in curses mode, it means we have
read data from standard input, either from the keyboard or from a pipe.
In the latter case, we first need to reconnect standard input to the tty.
And in both cases, we then need to reenter curses mode before being able
to display the number of lines that were read (or an error message).
So, move the reconnecting code from scoop_stdin() to its own function,
and call this function from read_file() when needed.
This fixes https://savannah.gnu.org/bugs/?56310.
Bug existed since version 2.1.8 when reading from stdin was introduced.
The 'quiet' parameter is only used when opening a help-text tempfile
or a spell-checked tempfile, and these files necessarily exist, so
'quiet' will never be checked for them. But in the weird case that
the help-text tempfile could not be opened, it is not a problem that
"New File" gets printed to the status bar because nano will crash
shortly afterwards. And when the spell-checked tempfile could not
be opened, a "Not Found" message is appropriate, but nano will crash
in this case too.
Trying to append does not work on a fifo, and we'd like to be able to
open a fifo again. Also, the append test causes a close event for the
given file at the moment of opening it, which makes using 'inotify' for
waiting for this file to be closed useless.
Commit f8f90272 added the append test, but the original request
(https://lists.gnu.org/archive/html/info-nano/2009-05/msg00000.html
by Damien Joldersma) asked only for a warning when the user did not
have enough privileges to write to the file.
So, drop the append test and just check the access bits.
This fixes https://bugs.debian.org/583196
and fixes https://savannah.gnu.org/bugs/?29312.
The original requests (https://bugs.debian.org/551717 by Paul Wise,
and https://savannah.gnu.org/bugs/?45383 by Mike Frysinger) asked
only that specifying a directory instead of a file name should not
open a new buffer. But commit 98ffb642 excluded everything that was
not a normal file. This avoids a hang when the user accidentally
tries to open a pipe or a socket, but also prevents any user from
doing so on purpose. And opening a fifo can be useful when wanting
to handle sensitive data that shouldn't be stored on disk.
This prepares the fix for https://bugs.debian.org/583196.
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.
The lack of initialization caused a nasty bug on some targets (such as
ARMv7) which would make it so that ^S would just say "Cancelled".
While x86 (both 64 and 32 bits) seems to initialize 'response' to zero or
a positive number, ARM does not, and there is usually a negative value in
its place, which triggers the 'if (response < 0)' check and, as a result,
the code says "Cancelled".
This fixes https://savannah.gnu.org/bugs/?56023.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since version 4.0, commit 0f9d60a3.
Signed-off-by: Devin Hussey <husseydevin@gmail.com>
The user did not move the cursor nor intend to move the cursor, so
leave things as they are.
This fixes https://savannah.gnu.org/bugs/?55535.
Indirectly-reported-by: David Lawrence Ramsey <pooka109@gmail.com>
This function allows the user to "make space": annihilating lines or
regions while keeping intact for pasting the stuff in the cutbuffer
that was cut or copied earlier.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
When --view is used without --ignorercfiles, the user could view
other files anyway if they had 'set multibuffer' in their nanorc.
So, just make this the default when --view is used, also because
"multibuffer" cannot be toggled once nano is running in view mode.
When the viewing of other files in view mode should not be allowed,
one should now additionally use --restricted.
When 'inhelp' is true, there are at least two buffers open: an
edit buffer and the help-text buffer.
And bottombars() already does a full refresh of the bottom window.
The crawl needs at least five rows to be perceived as a crawl, and
the widest line is 31 characters (ignoring translations, which might
be even longer). Formerly, when only two or three rows were available,
nothing was shown at all, which was puzzling. So, better do the credits
only when there is room enough for them, and print a message otherwise.
When switching to a different buffer, don't just show its name but
also the number of lines it contains. This is useful extra info.
Then use this same message when at startup multiple files are opened
and (after reading them all) we switch back to the first buffer.
(This loses, when multiple files are opened, the information about
format conversion that nano still shows when a single file is opened,
but... this bug has shown that people don't really look at this line
anyway, so... let it be. The info can still be seen when writing out
the file with ^O.)
This addresses https://savannah.gnu.org/bugs/?54047.
Unlike glibc, which in getc() locks the file only when it is needed,
FreeBSD and Bionic libc will always lock the file, causing a massive
slowdown, as the system has to create and destroy a mutex each time
getc() is called.
Avoid that massive overhead by locking the file before starting to read
and unlocking it after reading is complete, and using getc_unlocked() to
read each byte. This makes reading on FreeBSD/macOS and Android anywhere
from 2 to 6 times faster, and on glibc roughly seventy percent faster.
This partially addresses https://savannah.gnu.org/bugs/?50406.
Signed-off-by: Devin Hussey <husseydevin@gmail.com>
The only time that feedback about the number of lines written is *not*
wanted is when writing a temporary file.
This fixes https://savannah.gnu.org/bugs/?54025.
When executing a command, it is now possible to pipe the entire buffer
(or the marked region, if anything is marked) to the external command.
The output from the command replaces the buffer (or the marked region),
or goes to a new buffer.
This fulfills https://savannah.gnu.org/bugs/?28993,
and fulfills https://savannah.gnu.org/bugs/?53041.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
When the file has just been read, it is in the state that it has
on disk, so there is nothing to undo.
This fixes https://savannah.gnu.org/bugs/?53387.
That is, call display_string() just on the filename, not on the rest
of the prompt text.
This fixes https://savannah.gnu.org/bugs/?52967.
Reported-by: Andreas Schamanek <schamane@fam.tuwien.ac.at>
Each leading tab is converted to two tabs, and any leading four spaces
is converted to one tab. The intended tab size (for keeping most lines
within 80 columns) is now four.
Unset the "Modified" marker only at the point where the file was last
saved -- if there is such a point, because it can be missing when the
undo stack was discarded.
This fixes https://savannah.gnu.org/bugs/?52689.
Reported-by: Liu Hao <lh_mouse@126.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
This also means that no question needs to be asked when exiting.
This fixes https://savannah.gnu.org/bugs/?52504.
Reported-by: Peter Passchier <peter@passchier.net>
The pointer not being NULL is enough indication that the mark is set.
Also, rename the pointer from 'mark_begin' to simply 'mark', since
the former is kind of pleonastic.
In the tiny version, do_prompt() will now have an extra NULL
parameter, which will cost maybe twenty extra bytes of code.
That is acceptable when it saves thirty lines in the source.
The key sequence ^R ^X M-F <Enter> would cause nano to abort, because
it would try to add an empty string to a history list. (Furthermore,
simply don't execute an empty command, because it is pointless.)
Reported-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
^S will be the first thing people will try for saving a file,
and ^Q is somewhat mnemonic because it is to the left of ^W:
it searches backward.
Make these keystrokes available also in the tiny version.
Before writing a file out, nano should check that the file on disk
hasn't been modified since it was read -- not only for the normal
"Write Out" action (^O), but also for "Save File" (future ^S) and
for "Save and Exit" (^X when --tempfile is used).
When writing fails and --tempfile is in effect, don't go on to prompt
for a file name; instead let the user decide what she wants to do.
This fixes https://savannah.gnu.org/bugs/?51040.
Signed-off-by: Viorel Bota <botaviorel@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Benno Schulenberg