James McCoy wrote: > 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
Whas there a patch for this? -- We are the Borg of GNU GPL. We will assimilate your source code. Resistance is futile. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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.
