Avoid having to decrement the count in order to offset the increment
at the end of the loop.
Also, declare a variable on a separate line, and rename it.
First cutting the text to be copied (before copying it back into the
buffer) had unwanted side effects: it moved the cursor, and changed
the linestructs of the current line and the line where the mark was.
[This takes thirty more lines, but the idea is to later get rid of
the partitioning routines entirely.]
This means that in most cases mark_is_before_cursor() is called twice:
once before get_region() is called, and once by get_region() itself.
This small duplication of effort is acceptable: the affected functions
are not time critical, and it makes the code shorter.
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.)
Benno Schulenberg