I did not more digging and realized that vim has already had a mechanisms to transform input/output streams. I will try BufReadCmd/BufWriteCmd later.
Thanks. On Thursday, June 9, 2016 at 9:34:42 AM UTC-4, cryptoz wrote: > On Thursday, June 9, 2016 at 5:34:10 AM UTC-4, Ken Takata wrote: > > Hi cryptoz, > > > > 2016/6/9 Thu 15:53:05 UTC+9 cryptoz wrote: > > > I have followed instructions on the Internet to edit gpg encrypted text > > > file transparently. It almost works, but the file format is messed up for > > > gpg files. > > > > > > OS: Windows 10. > > > vim version: 7.4.1023 and 7.4.1721 (tried both) > > > > > > Problems: > > > > > > Suppose I have a file a.txt. It has only one character in it (say, 'a'). > > > The file has three bytes: > > > > > > 00000000: 61 0d 0a > > > > > > If I encrypted the file with gpg without armor, the output file has > > > hundreds of binary data. When I opened the gpg file with vim, there is an > > > ^M at the end of the line. > > > > > > The fileformats is set to dos,unix and fileformat (detected) is dos. > > > > > > If I use armored file (.asc), there is no issue. > > > > > > The script I put in _vimrc to open *.gpg,*.asc files is similar to what I > > > got from http://vim.wikia.com/wiki/Encryption > > > > > > I understand correctly, the steps are: > > > > > > 1. set bin option before read the file. > > > 2. read the file into buffer. > > > 3. call gpg to decrypt the buffer. > > > 4. set nobin option. > > > > > > I am not sure when fileformat is detected during this process. I tried to > > > set fileformat to dos in each step, it did not work. > > > > > > The problem could be the fileformat detection is done in 2. Since it is a > > > binary file, fileformat is set to unix. In step 3, when decrypted text is > > > placed back in buffer, there is ^M at the end of each line because > > > fileformat > > > is already set to unix. > > > > > > I would think a better way to handle similar situations is add a user > > > configurable filter to convert the stream read from the file into another > > > format (e.g., decryption, encoding) and another filter one for writing. > > > > > > Thanks. > > > > I see a similar problem when I use a setting written in `:help hex-editing`: > > > > augroup Binary > > au! > > au BufReadPre *.bin let &bin=1 > > au BufReadPost *.bin if &bin | %!xxd > > au BufReadPost *.bin set ft=xxd | endif > > au BufWritePre *.bin if &bin | %!xxd -r > > au BufWritePre *.bin endif > > au BufWritePost *.bin if &bin | %!xxd > > au BufWritePost *.bin set nomod | endif > > augroup END > > > > When I open a *.bin file on Windows with this setting, each line ends with > > ^M. > > The following setting seems to fix the problem: > > > > augroup Binary > > au! > > au BufReadPre *.bin let &l:bin=1 > > au BufReadPost *.bin if &bin | setlocal nobin nofixeol ff=unix | %!xxd > > au BufReadPost *.bin setlocal ft=xxd | endif > > au BufWritePre *.bin if &ft=="xxd" | setlocal bin | %!xxd -r > > au BufWritePre *.bin endif > > au BufWritePost *.bin if &ft=="xxd" | setlocal nobin | %!xxd > > au BufWritePost *.bin setlocal nomod | endif > > augroup END > > > > (Sorry, not tested well.) > > > > Maybe we need `set nobin` before reading from a filter and `set bin` before > > writing to a filter. 'fixeol' and 'ff' should be also adjusted properly. > > ('fenc' should be also adjusted?) > > > > Regards, > > Ken Takata > > Thank you, Ken. > > It seems working in the sense that ^M is removed. > > I added a line before sending everything to the filter. > > autocmd BufReadPre,FileReadPre *.gpg setlocal bin > autocmd BufReadPost,FileReadPost *.gpg setlocal nobin nofixeol ff=unix > autocmd BufReadPost,FileReadPost *.gpg,*.asc '[,']!gpg -q --decrypt 2>NUL > > The setlocal nobin line is the newly added one. > My understanding is that when feeding lines to the filter, try to make it > binary (using nofixeol and ff=unix). When reading lines from the filter, > treat them as text ( the nobin option). > > I also think there may be cases this method does not work (or not perfectly). > As fileformat is set to unix before using the filter, the output of the > filter should be unix. This may not be true for the program used in the > filter and sometimes it is hard to change the behavior. > > Another issue is that the fileformat is set to unix manually, the original > end of line is lost. When saving the file, the end of line is set to unix > (when the bin option is set before using the output filter). > > So I think this method can remove ^M at the end of lines if the end of lines > in the original file (in my case, the file before encryption) is dos style. > When saving the file, the end of lines changes to unix style. > > A better way to handle this could be a new function in vim: the input and > output format of the filter can be configured separately. When decrypting, > the input to the filter is binary and output is text. When encrypting, the > input is text and output is binary. > > Another option could be to use a hidden buffer. It can be tedious to save, > restore and copy settings between buffers. > > Best, > > cryptoz -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
