When bufwinnr() returns -1, the buffer isn't currently displayed. In
this case, we need to return so the contents of a different buffer
aren't used for recipients/options.
The BufHidden autocommand will have already called the respective Finish
function. Clearing the autocommands during BufUnload ensures they don't
inadvertently run when Vim is shutting down.
Closesjamessan/vim-gnupg#104
These are typically test files, but a good idea not to accidentally add
encrypted files to the repo.
Signed-off-by: James McCoy <jamessan@jamessan.com>
This allows for easier on-the-fly debug (e.g., ":verbose w") and also
makes it easy to leverage 'verbosefile'.
Signed-off-by: James McCoy <jamessan@jamessan.com>
Instead of assuming a single line is output, which may be wrong in error
conditions, use the '[/'] marks to delete everything that was read.
Closesjamessan/vim-gnupg#106
Signed-off-by: James McCoy <jamessan@jamessan.com>
This allows them to be properly cleared only when the buffer is
re-created/loaded. This fixes the handling of the autocmds when the
Edit buffer is saved, but not hidden or deleted.
The autocmd remains in place, rather than having an acwrite buffer with
no autocmd set.
Signed-off-by: James McCoy <jamessan@jamessan.com>
BufWriteCmd writes the whole buffer, so it can use the bare ":w". Other
plugins may manipulate the '[/'] marks on save, which can cause the
write with marks to not write the entire buffer.
Closes: jamessan/vim-gnupg#96
Signed-off-by: James McCoy <jamessan@jamessan.com>
Since buffer numbers are unique in Vim, there's no concern about
collisions between options/recipients buffers for different encrypted
buffers.
This also resolves an issue where opening the options buffer would
trigger the recipients buffer (due to the buffer name matching
g:GPGFilePattern.
Closesjamessan/vim-gnupg#89
Signed-off-by: James McCoy <jamessan@jamessan.com>
FileReadCmd reads the contents of another file into the current buffer.
Therefore, it should honor the settings ('buftype' and :file) of the
current buffer.
Closesjamessan/vim-gnupg#86
Signed-off-by: James McCoy <jamessan@jamessan.com>
If the buffer is being saved to a different filename, then this buffer
should still be modified as its backing file is still different than the
buffer.
Signed-off-by: James McCoy <jamessan@jamessan.com>
If buftype=acwrite, Vim doesn't adjust relative buffer names when
changing directory. Since 5103285d, encrypted buffers have set
buftype=acwrite and therefore also risked having incorrect buffer names
(e.g., if 'autochdir' is set).
Now that the buffer name is always fully resolved, this should no longer
be a problem.
Closesjamessan/vim-gnupg#81
Signed-off-by: James McCoy <jamessan@jamessan.com>
The user may be a) editing an existing encrypted file, b) creating a new
encrypted file, c) editing an unnamed buffer and saving it as an
encrypted file. In all cases, 'buftype' should be set correctly once we
know the buffer is intended to be encrypted.
Signed-off-by: James McCoy <jamessan@jamessan.com>
Gpg4win expects native Windows paths even when it's being run from a
cygwin environment. In order to satisfy that, update `s:shellescape` to
know whether it should convert the paths to native Windows paths using
`cygpath -am`.
In order to detect whether cygpath should be invoked, look for the
combination of `has('win32unix')` being true and `gpg --version`
reporting a Windows style path for gpg's home directory.
Closesjamessan/vim-gnupg#62
Signed-off-by: James McCoy <jamessan@jamessan.com>
This ensures any write of the buffer requires a configured BufWriteCmd
autocmd, providing more safe guards against problems like
jamessan/vim-gnupg#77.
Signed-off-by: James McCoy <jamessan@jamessan.com>
If 'autowrite' is set, an encrypted buffer is modified, and ":q!"/"ZQ"
is executed, GPGCleanup's "only!" would cause the buffer to be
abandoned. Due to 'autowrite' and the VimLeave autocmd not using
"nested", abandoning the buffer causes Vim to write the buffer, which is
currently unencrypted, overwriting the encrypted file with plain text.
Since the user can more reliably clear their own console/terminal scroll
back than we can, simply remove this functionality. It's safer than
trying to unwind the twisty passages of Vim's autocmds, especially those
of the *WriteCmd variety.
Closesjamessan/vim-gnupg#77
Signed-off-by: James McCoy <jamessan@jamessan.com>
In the refactor to use the *Cmd events, an unencrypted file was simply
:read into the buffer. This incorrectly caused an extra blank line to
be added to the top of the buffer.
The handling of encrypted files properly handles this, as well as
triggering BufRead(Pre,Post) events.
Instead of returning early for unencrypted files, go through the same
steps as for encrypted files (minus the encryption specific steps), thus
preserving the content of the original file.
In dda14abb3c, GPGCleanup added 'set
buffhidden=hide' to try avoiding error messages when modified buffers
are being abandoned. However, that only works if the buffer is the last
visible buffer.
If there are windows displaying multiple buffers, then errors can still
be emitted. Using "only!" ensures all the other windows can be closed.
Signed-off-by: James McCoy <jamessan@jamessan.com>
When Vim has decided it can exit, GPGCleanup forces a blank buffer to
take over the screen so contents aren't visible in scrollback. However,
if the buffer is modified and 'hidden' isn't set then the command will
fail.
Force the buffer to be hidden, so this is avoided.
Signed-off-by: James McCoy <jamessan@jamessan.com>
Since the user can control which file patterns are handled by the plugin
(via g:GPGFilePattern), the regular expression checking the buffer name
for GPGEdit{Recipients,Options} may not match. A simpler and more
definitive check is to see whether b:GPGCorrespondingTo is set to
determine if the buffer is an existing recipients/options buffer.
Closesjamessan/vim-gnupg#72
Signed-off-by: James McCoy <jamessan@jamessan.com>
Changing &encoding when &fileencoding != &encoding causes two problems.
First, it's completely unsafe to change &encoding after vim is running,
since there may be characters that can't be translated from one encoding
to another, which can make vim crash.
Second, this actually loses information about the buffer's encoding.
When the encrypted file is opened later, it won't be in the same
encoding as before it was saved. Changing user's data on them is
unacceptable.
Signed-off-by: James McCoy <jamessan@jamessan.com>
If the user is using "vim -R"/":view", then the opened buffer should
have 'readonly' set, even if permissions would otherwise allow editing.
Closesjamessan/vim-gnupg#67
Signed-off-by: James McCoy <jamessan@jamessan.com>
When the user hasn't explicity let g:GPGPreferArmor, the value is
supposed to be determined by the filename. Instead of letting
g:GPGPreferArmor, lazily determine what should be done when actually
doing the encryption.
Signed-off-by: James McCoy <jamessan@jamessan.com>
Renaming the temporary, encrypted file to the intended filename (per the
buffer) may fail (e.g., typoed directory name). In this case, remove
the temporary file and then give the typical error message for this
situation.
In order to be safe, the message is manually being generated instead of
trying to be clever and do something like “noautocmd write” expecting it
to hit the same error that rename() did.
Closesjamessan/vim-gnupg#56
Signed-off-by: James McCoy <vega.james@gmail.com>
