Closed amerlyq closed 8 years ago
I don't know much about NeoBundle, but you could try reloading the buffer instead.
if neobundle#tap('vim-gnupg') "{{{
fun! neobundle#hooks.on_post_source(bundle)
edit
endf
call neobundle#untap()
endif "}}}
Your current doautocmd
isn't working because BufReadCmd
isn't a command. It's an autocommand event. You could try silent! exe 'doautocmd BufReadCmd' expand('%')
but I don't think that will work well with a buffer that already has been loaded.
Regretfull, but simple edit
inside hook didn't worked at all.
Your alternative command is completely equivalent to mine, so it didn't worked either.
Could you specify supposed order in callstack of your functions, when you do $ vim file.gpg
?
I can't comprehend how all used autocmd (with respawned doautocmd) finally ordered, so don't know which function wasn't called at all and where manual initialization went wrong.
After discussing with Shougo and specifying additional option, results somewhat changed, and somewhat not: buffer contains as earlier mixed enc and dec text, but now I can't undo dec text by 'u' -- so changestack is empty.
Please, do some tests on your side with this minimal vimrc. Maybe, you could slightly refactor your plugin's architecture to mitigate this issue?
set nocompatible
set encoding=utf-8
let $NEOBUNDLE=expand('/tmp/bundle/neobundle.vim')
if !filereadable(expand('$NEOBUNDLE/README.md'))
exe printf('!git clone --depth=1 %s',
\ 'https://github.com/Shougo/neobundle.vim') $NEOBUNDLE
endif
set runtimepath^=$NEOBUNDLE
let g:neobundle#default_options = {}
let g:neobundle#types#git#default_protocol = 'https'
let g:neobundle#types#git#clone_depth = 1
let g:neobundle#types#git#enable_submodule = 1
call neobundle#begin(expand('/tmp/bundle'))
NeoBundleFetch 'Shougo/neobundle.vim' " Manage self by itself
" \ 'filename_patterns': ['\.gpg$', '\.asc$', '\.pgp$']
NeoBundle 'jamessan/vim-gnupg', {
\ 'explorer': '.*\.\(gpg\|asc\|pgp\)$',
\ 'lazy': 1,
\ }
if neobundle#tap('vim-gnupg') "{{{
fun! neobundle#hooks.on_post_source(bundle)
" edit
silent! exe 'doautocmd BufReadCmd' expand('%')
" silent! exe 'doautocmd FileReadCmd' expand('%')
" silent! exe 'doautocmd GnuPG BufReadCmd'
endf
call neobundle#untap()
endif "}}}
call neobundle#end()
filetype plugin indent on " Required!
syntax enable
NeoBundleCheck
You're right, silent! doautocmd GnuPG BufReadCmd
should work, at least as far as I understand how NeoBundle works.
Doing a little searching on GitHub, other people have NeoBundle configurations for vim-gnupg.
Since I don't use NeoBundle though, I can't verify how well they work. If you confirm a working setup, I'll be glad to add documentation about it.
I found not such many examples of NeoBundleLazy
applied to vim-gnupg
on net.
And can assure all of them are broken the same way. Some even don't work at all the way they are configured.
This only indicates, they have installed but never really used vim-gnupg
or temporarily tried different configurations to fix issue with vim-gnupg
, as do I.
I compared two logs of your plugin on opening *.gpg -- normal and lazy.
Seems like in normal operation regime s:GPGInit(0)
never called.
Therefore doing manually doautocmd BufReadCmd
is wrong method.
Seems like current initialization process has excess dependencies?
# Normal log
GnuPG: >>>>>>>> Entering s:GPGInit(1)
GnuPG: gnupg.vim 2.5
GnuPG: shellredirsave: >%s 2>&1
GnuPG: shellsave: /usr/bin/zsh
GnuPG: shelltempsave: 1
GnuPG: shell: /bin/sh
GnuPG: shellcmdflag: -c
GnuPG: shellxquote:
GnuPG: shellredir: >%s 2>&1
GnuPG: stderrredirnull: 2>/dev/null
GnuPG: shell implementation: /usr/bin/bash
GnuPG: command: gpg --trust-model always --version 2>/dev/null
GnuPG: rc: 0
GnuPG: output: gpg (GnuPG) 2.1.9 <...>
GnuPG: public key algorithms: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
GnuPG: cipher algorithms: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
GnuPG: hashing algorithms: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
GnuPG: compression algorithms: Uncompressed, ZIP, ZLIB, BZIP2
GnuPG: <<<<<<<< Leaving s:GPGInit()
GnuPG: >>>>>>>> Entering s:GPGDecrypt(1)
GnuPG: command: gpg --trust-model always --use-agent --verbose --decrypt --list-only --dry-run --no-use-agent --logger-fd 1 '/home/user/file.gpg' 2>/dev/null
GnuPG: rc: 0
GnuPG: output: gpg: armor header: Version: GnuPG v2^@gpg: public key is ...^@
GnuPG: this file is asymmetric encrypted
GnuPG: recipient is ...
GnuPG: >>>>>>>> Entering s:GPGNameToID()
GnuPG: command: gpg --trust-model always --use-agent --quiet --with-colons --fixed-list-mode --list-keys '...' 2>/dev/null
GnuPG: rc: 0
GnuPG: output: <...>
GnuPG: <<<<<<<< Leaving s:GPGNameToID()
GnuPG: name of recipient is EF1F9DEFA882D481
GnuPG: called BufReadPre autocommand for mutt
GnuPG: this file is armored
GnuPG: decrypting file
GnuPG: command: silent r !gpg --trust-model always --use-agent --quiet --decrypt '/home/user/file.gpg' 2>/dev/null
GnuPG: rc: 0
GnuPG: called BufReadPost autocommand for mutt
GnuPG: <<<<<<<< Leaving s:GPGDecrypt()
GnuPG: >>>>>>>> Entering s:GPGCleanup()
GnuPG: <<<<<<<< Leaving s:GPGCleanup()
And if I do manual doautocmd BufReadCmd
-- log will be more long, repeating upper parts and adding new
# all upper mentioned log
...
...
GnuPG: >>>>>>>> Entering s:GPGInit(1)
GnuPG: gnupg.vim 2.5
GnuPG: shellredirsave: >%s 2>&1
GnuPG: shellsave: /usr/bin/zsh
GnuPG: shelltempsave: 1
GnuPG: shell: /bin/sh
GnuPG: shellcmdflag: -c
GnuPG: shellxquote:
GnuPG: shellredir: >%s 2>&1
GnuPG: stderrredirnull: 2>/dev/null
GnuPG: shell implementation: /usr/bin/bash
GnuPG: command: gpg --trust-model always --version 2>/dev/null
GnuPG: rc: 0
GnuPG: output: gpg (GnuPG) 2.1.9 <...>
GnuPG: public key algorithms: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
GnuPG: cipher algorithms: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
GnuPG: hashing algorithms: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
GnuPG: compression algorithms: Uncompressed, ZIP, ZLIB, BZIP2
GnuPG: <<<<<<<< Leaving s:GPGInit()
GnuPG: >>>>>>>> Entering s:GPGDecrypt(1)
GnuPG: command: gpg --trust-model always --use-agent --verbose --decrypt --list-only --dry-run --no-use-agent --logger-fd 1 '/home/user/file.gpg' 2>/dev/null
GnuPG: rc: 0
GnuPG: output: gpg: armor header: Version: GnuPG v2^@gpg: public key is ...^@
GnuPG: this file is asymmetric encrypted
GnuPG: recipient is ...
GnuPG: >>>>>>>> Entering s:GPGNameToID()
GnuPG: command: gpg --trust-model always --use-agent --quiet --with-colons --fixed-list-mode --list-keys '...' 2>/dev/null
GnuPG: rc: 0
GnuPG: output: <...>
GnuPG: <<<<<<<< Leaving s:GPGNameToID()
GnuPG: name of recipient is ...
GnuPG: called BufReadPre autocommand for mutt
GnuPG: this file is armored
GnuPG: decrypting file
GnuPG: command: silent r !gpg --trust-model always --use-agent --quiet --decrypt '/home/user/file.gpg' 2>/dev/null
GnuPG: rc: 0
GnuPG: called BufReadPost autocommand for mutt
GnuPG: <<<<<<<< Leaving s:GPGDecrypt()
GnuPG: >>>>>>>> Entering s:GPGCleanup()
GnuPG: <<<<<<<< Leaving s:GPGCleanup()
This overwrites decrypted text by encrypted and again by decrypted -- therefore they appear one on top of another, messing buffer content.
If I use doautocmd BufReadCmd
and doautocmd FileReadCmd
-- all lines in decrypted buffer will be doubled. Please, check your autocmds and how you distributed plugin initialization through all those pieces.
Seems like in normal operation regime s:GPGInit(0) never called.
That's expected. s:GPGInit(0)
is only going to be called if FileReadCmd
was triggered.
Therefore doing manually doautocmd BufReadCmd is wrong method.
Yes, it is, so why are you doing it? The plugin is designed to handle reading the file into the buffer. You're interfering with that by lazily loading the plugin and then trying to replicate its behavior.
If you want the plugin to do its job properly, then you actually need to reload the buffer, which is done by a no-argument :edit
once the plugin has been loaded.
I have next recipe for NeoBundle
And corresponding part in vimrc
So, I assumed that calling BufReadCmd will do the work. It seems not so, because on manual calling autocmd, instead of usual behaviour, only first several lines of encrypted text are rewritten (with exact decrypted text). And by using 'u' I can undo this text back to encrypted container -- which wierd. Which steps I must manually do in on_post_source or on_source hooks to complete expected initialization of this plugin?