Hi Bram, On Sat, Dec 06, 2014 at 07:44:30PM -0500, James McCoy wrote: > On Sat, Dec 06, 2014 at 05:49:13AM +0100, Bram Moolenaar wrote: > > > > James McCoy wrote: > > > > > Using a Vim that is built to be able to access X's PRIMARY and CLIPBOARD > > > selections (i.e., "* and "+), performing “:let &term=&term” causes Vim > > > to "forget" that it knows how to access those registers. > > > > > > This is because set_termname() ends up calling clip_init(), which sets > > > owned = FALSE on both VimClipboard instances. > > > > > > I'm not sure why changing &term should be modifying the state of the > > > clipboard at all, so the attached patch removes that bit of the code, > > > resolving the bug. > > > > Well, setting the 'term' option sort of means a reset of the terminal. > > Why would you set the 'term' option while something is selected? > > This isn't purely about having something selected. Besides, Vim writes > to "* and "+ in cases other than just ":set clipboard=autoselect", so > it's more related to whether Vim has asserted ownership of a specific X > selection and no other app has taken that ownership in the interim. > > When one copies something to "+, Vim asserts ownership of the CLIPBOARD > selection. Performing "let &term=&term" makes Vim forget how to access > those registers. This means that the following sequence will result in > unexpected behavior: > > In Vim: > "+yy -- Asserts CLIPBOARD ownership with some contents > > In some other app: > <C-v> -- Pastes those contents > > In Vim: > :let &term=&term > > In some other app: > <C-v> -- Doesn't paste anything > > Even worse is the reverse: > > In some other app: > <C-c> -- copy some text > > In Vim: > :let &term=&term > "+p -- The contents of the default register are pasted > > To top it off, I haven't yet found a way to make Vim re-realize it can > talk to X, so basically vim (at least from the terminal) is completely > cut off after that code is executed. > > Thanks for prodding me to look into the behavior more, as I know feel > even more strongly that the code should be removed.
Any chance of revisiting my proposed patch given the above behaviors? If not, what behavior requirements would you want from a patch? I'd like to get this fixed. The original reason I ran into this is that Vim's understanding of the terminal state is broken after running ":!gpg --decrypt ..." (which affects users of my vim-gnupg plugin[0]) due to pinentry and Vim both messing with terminal state. In order to work around this, until I can understand whether and how Vim or pinentry needs to be fixed, I have to reset 'term' to make Vim re-understand what the terminal does. [0]: https://github.com/jamessan/vim-gnupg/issues/36 Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <[email protected]> -- -- 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.
signature.asc
Description: PGP signature
