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>
When --throw-keyids, --hidden-recipient, or --hidden-encrypt-to were
used for an encrypted file, the encryption metadata uses all zeroes as
the key ID. Ignore these key IDs to avoid generating extraneous
messages during decryption or adding invalid IDs to the recipients list.
Closesjamessan/vim-gnupg#50
Signed-off-by: James McCoy <vega.james@gmail.com>
If a user has 'shellslash' set in Windows, then filename related
functionality uses forward slashes instead of backslashes. This breaks
running of external commands because some external commands in Windows
treat any forward slash as a command line switch.
This change adds s:shellescape(), which wraps Vim's shellescape(), but
ensures 'noshellslash' is set first in Windows command prompt (not
Cygwin or msys) environments. Having 'noshellslash' set when
shellescape() is called causes the string to be quoted, regardless of
whether there is whitespace or typical special characters, thus avoiding
the interpretation of the string as being command line switches.
Closesjamessan/vim-gnupg#41
Signed-off-by: James McCoy <vega.james@gmail.com>
In non-Windows environments, the gpg command is prepended with “LANG=C
LC_ALL=C” to ensure gpg's output is consistent to allow for parsing the
information. However, that doesn't work in Windows and won't
necessarily work if we ever remove the code forcing use of /bin/sh.
Since Vim already knows how to influence the environment, use its
“:language message …” command to set/restore the locale before/after
running the gpg command.
Closesjamessan/vim-gnupg#45
Signed-off-by: James McCoy <vega.james@gmail.com>
If the “log-file” option is set in ~/.gnupg/gpg.conf, then using “--batch”
means that the CLI's “--logger-fd” is ignored. Since this command
shouldn't need any of “--batch”'s functionality and “log-file” hides all
the output we're expecting, dropping “--batch” is the sane thing to do.
Closes#40
Signed-off-by: James McCoy <vega.james@gmail.com>
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
# modified: plugin/gnupg.vim
#
# Untracked files:
# foo.asc
# foo.gpg
# foo.sig
#
# ------------------------ >8 ------------------------
# Do not touch the line above.
# Everything below will be removed.
diff --git c/plugin/gnupg.vim i/plugin/gnupg.vim
index 80f2061..b0bcd5c 100644
--- c/plugin/gnupg.vim
+++ i/plugin/gnupg.vim
@@ -1,5 +1,5 @@
" Name: gnupg.vim
-" Last Change: 2015 Jul 16
+" Last Change: 2015 Jul 26
" Maintainer: James McCoy <vega.james@gmail.com>
" Original Author: Markus Braun <markus.braun@krawel.de>
" Summary: Vim plugin for transparent editing of gpg encrypted files.
@@ -448,7 +448,7 @@ function s:GPGDecrypt(bufread)
" find the recipients of the file
let cmd = { 'level': 3 }
- let cmd.args = '--verbose --decrypt --list-only --dry-run --batch --no-use-agent --logger-fd 1 ' . shellescape(filename)
+ let cmd.args = '--verbose --decrypt --list-only --dry-run --no-use-agent --logger-fd 1 ' . shellescape(filename)
let output = s:GPGSystem(cmd)
" Suppress the "N more lines" message when editing a file, not when reading
Starting with release 2.1, gnupg will automatically run gpg-agent rather
than requiring it to be run as a daemon. The “--no-use-agent” switch
was also marked deprecated, since it no longer does anything.
This commit moves the --(no-)use-agent handling until after it is known
what version of gpg is being used.
Closes#37
Signed-off-by: James McCoy <vega.james@gmail.com>
Resetting &term can affect various settings which are terminal
dependent (e.g., escape sequences described at “:help :set-termcap”).
Emitting TermChanged allows people to re-set these options so they don't
lose functionality (c.f. jamessan/vim-gnupg#28).
Signed-off-by: James McCoy <vega.james@gmail.com>
:lockmarks doesn't appear to preserve these marks. They would need
to be adjusted anyway due to the line numbers changing, so just set the
marks to the start/end of the buffer.
Signed-off-by: James McCoy <vega.james@gmail.com>
After Vim runs certain commands (e.g., pinentry-curses), the terminal is
not returned to its previous state. This causes some escape sequences,
like arrow keys, to stop being recognized properly by Vim.
Re-setting &term to itself causes Vim to go through its normal terminal
initialization steps which gets things back in working order.
Closesjamessan/vim-gnupg#17
Signed-off-by: James McCoy <vega.james@gmail.com>
Allow to set initial contents for recipients menu with
g:GPGRecipientsMenu. Example usage:
let g:GPGRecipientsMenu=""
\."GPG: Example User <example@example.com>\<NL>"
\."GPG: Other User <otherexample@example.com>\<NL>"
glob() reports false positives if the filename has metacharacters in it
(e.g., "[...]"), which causes Vim to incorrectly open a new, blank
buffer instead of the specified file.
Closesjamessan/vim-gnupg#12
Signed-off-by: James McCoy <vega.james@gmail.com>
