"let &term=&term" clears state of X selection access

[James McCoy]

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.

Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jame...@jamessan.com>

[Daniel Hahler]

Thanks for your patch.

I have not tried it, but looked at the "blame" for that part of the file, and it is from the beginning of the history (2004-06-13, Vim 7).


Regards,
Daniel.

[James McCoy]

On Fri, Dec 05, 2014 at 01:50:13PM -0800, Daniel Hahler wrote:
> I have not tried it, but looked at the "blame" for that part of the
> file, and it is from the beginning of the history (2004-06-13, Vim 7).

It actually goes all the way back to the initial import of Vim into CVS
in 1999 --
http://vim.cvs.sourceforge.net/viewvc/vim/vim/src/term.c?revision=1.1&view=markup

I'm unsure if my patch is the right fix, but that's mainly because I
don't understand why this code was there in the first place.

[Bram Moolenaar]

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?


--
DENNIS: Look, strange women lying on their backs in ponds handing out
swords ... that's no basis for a system of government. Supreme
executive power derives from a mandate from the masses, not from some
farcical aquatic ceremony.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///

[James McCoy]

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.

[Christian Brabandt]

Hi James!

On Sa, 06 Dez 2014, James McCoy wrote:

> 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.

Indeed, I have also just recently (with the inclusion of patch 7.4.523
where Vim would try to reconnect to the X11 server but just once) asked,
whether it would make sense to have a dedicated command to make Vim
reinitialize the X server connection:

https://groups.google.com/d/msg/vim_dev/gareY-F4jNg/jfhWry7NmasJ

Best,
Christian
--

[James McCoy]

Hi Bram,

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

[Bram Moolenaar]

Whas there a patch for this?

--
We are the Borg of GNU GPL. We will assimilate your source code.
Resistance is futile.