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>
This was lost in the refactor of external command handling, commit
7d102c843, and was causing an unnecessary "Press ENTER …" prompt to be
emitted whenever the buffer was written out.
Signed-off-by: James McCoy <vega.james@gmail.com>
If there are specific actions that should take place when editing a
GnuPG-managed buffer, an autocmd for the User event and GnuPG pattern
can be defined. For example, the following will set 'textwidth' to 72
for all GnuPG-encrypted buffers:
autocmd User GnuPG setl textwidth=72
This will be triggered before any BufRead or BufNewFile autocmds, and
therefore will not take precedence over settings specific to any
filetype that may get set.
Closesjamessan/vim-gnupg#10
Signed-off-by: James McCoy <vega.james@gmail.com>
The previous behaviour of this plugin was to open the recipient pane
immediately after opening a new file with the correct extension. The
documentation states that this should still occur, so this commit
implements the behaviour in a slightly different manner than the old
plugin.
If a user :w's when in the options or recipient panes the global
bufwrite handlers will be called, triggering an attempt to encrypt the
file. The user will be dropped into the command line recipient adding
process, and the recipients listed in the buffer will be ignored.
This commit checks to see if a buffer is a child of another by looking
for the buffer local var containing the parent buffer name, and only
runs the encryption if it is not present.
Need to use copy() when setting b:GPGRecipients in GPGDecrypt(), otherwise the local variable will act as a reference to the global one. The result will be that the global default recipient list will become a super-set of recipients as multiple gpg files are opened.
This can be really handy when using vim as an external editor
for a program (via temporary files) that you'd like to be able to
encrypt based on the temp file's name (for example, when using
vim as an external editor for Notational Velocity).
Previously, only a contiguous block of uids would be presented to the
user when trying to disambiguate a key. This happened because a key may
have other fields interspersed among the uids, like UAT.
Signed-off-by: James McCoy <vega.james@gmail.com>
This is a step towards reporting keys that aren't valid for encryption
instead of just ignoring them.
Signed-off-by: James McCoy <vega.james@gmail.com>
Using system('tty') will always report "not a tty", since the spawned shell
has stdin redirected. In order to get an accurate value for $GPG_TTY when
it's not already set, read the output of the tty command using :!.
This requires a bit more setup/teardown to ensure the buffer and user's undo
state aren't affected, but it's the only way to accurately determine the
user's tty.
Closes: #1
Signed-off-by: James McCoy <vega.james@gmail.com>
It's possible that gpg will work fine without $GPG_TTY being set (e.g., when
using a GUI pinentry program). Therefore, the message should be classified as
a warning, not an error.
Also, use a single :echom to ensure the user sees the entire message, not just
"gpg-agent might not work."
First part of GH #1
Signed-off-by: James McCoy <vega.james@gmail.com>
Whenever GPGFinishRecipientsBuffer is called, the buffer is processed to
convert names to IDs. However, this was ignoring any existing ID information
in the buffer. This meant that if a person had multiple keys, the user would
be prompted to disambiguate the keys after every :GPGEditRecipients session.
Parsing the ID out of the recipients buffer avoids the unnecessary prompting.
Signed-off-by: James McCoy <vega.james@gmail.com>
