Arch Linux

I think that is because the package has this option --with-x=no.
Vim is now much closer to what vi was until recently.

does it work when you shift-middleclick?

:set mouse=v

This has been broken for a long time with the upstream default settings (I use chroots so my $DISPLAY isn't set then, giving the same effects as compiling without X support).

":set mouse=v"

But that is the case with Vim in extra too. The report talks about some kind of "new behaviour".

The "new behaviour" already existed in the old package version in case $DISPLAY wasn't set. Personally, not having mouse=v in the default preferences, is a regression. The defaults must have been changed in some upstream release, but I haven't seen a distro other than Archlinux that has mouse=a as default setting.

This is new behavior for me since the version from testing was installed. It does not happen with the version from extra. I'm testing it right now and the two versions behave differently.

Egads! I just noticed dolby's post. If this option prevents users from using the X clipboard, then it's silly and is going to generate a ton of complaints amongst Arch users. I'm trying to test it and am currently waiting for the bazillion patches for vim to download.

I can't even build the version from testing. If this is a configuration issue, then it's not a bug and this report should be closed. On the other hand, it's ridiculous to not have the primary clipboard as a way to share information between vim and every other program that runs under X.

Thanks guys. I can confirm that enable ":set mouse=v" option restores ability to copy and paste with middle mouse button, although I still can't copy text from Vim and paste it into other X applications using Shift + Insert keys (it used to work fine in version 7.2.65-1).

The Shift + Insert method of copy and paste seems to works just fine when I copy and paste between Vim and terminal applications (or just terminal).

I'll rebuild the package with "--with-x=yes" option and see if it will change anything.

I've just rebuilt the Vim package from testing repository with "--with-x=yes" option and all of copy & paste methods (using middle click, Shift + Insert keys) is now working again. I can even copy and paste using middle click without having to first set ":set mouse=v" option.

So, could we have "--with-x=yes" as a default option again? I've use namcap to check the package and the only dependency "--with-x=yes" option added is libxt. Maybe we could even add libxt as an optional dependency if the package built just fine without it?

I can also confirm what dolby and zodmaner said. It took a bunch of tries for vim to build, but that has nothing to do with this.

I can also confirm that copy/pasting with the vim in testing is broken, so I reverted back to the version in extra. If "--with-x=yes" fixes it, please add it to the build.

Silly me, I've just figured this out:

Install gvim _also_ restored all of the old copy & paste functionalities to Vim running in terminal (obviously, since gvim is compiled with "--with-x=yes").

So, people who use Vim and want the old copy & paste behavior (especially the copy & paste functionalities between Vim in terminal and X applications) can just install gvim package and be done with it.

So, yeah... :-P

Thanks, that's a good thing to point out. It's a workaround and doesn't address the issue though. It'd be nice to know why --with-x was changed - whether or not there's an actual, practical reason that's worth breaking a most rudimentary and expected functionality - copy/pasting with a text editor of all things.

That is actually the intention of it. vim is supposed to be sparse, gvim is fully featured. After installing gvim, calling "vim" actually invokes a different binary, that is way more capable(but heavier, takes more memory etc.) Also note that vim has only Perl support, Python and Ruby come only after installing gvim.

for "testing": people can set their preferred behaviour in /etc/vimrc now, I will never overwrite this file. The satndard now does not set any mousebeehaviour explicitely