[vim/vim] Defaulting mouse=a in a terminal is incorrect (new as of 7.4.211) (#2841)
jrodman-tcell
Defaulting on the terminal mouse via defaults.vim breaks many expected behaviors, and should not be on by default, even when there is no .vimrc present.
In addition, this setting should lose to other settings in /etc if they express an alternate value that conflicts with the one in defaults.vim
Vim has a very long history of being conservative and reliable. I have generally trusted vim. This setting is far too aggressive. Today it has caused significant lost productivity, and there is no clear path towards resolving this for the future across the many environments where I will encounter vim. I cannot readily automate installing sanity on every image, vm, os, docker image, etc where I might expect vim to execute in the future.
I will not be surprised if this is a dupe, but I made a good faith effort to search for past issues, open or closed before creating it, and I feel it is a real and serious regression in vim behavior.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Bram Moolenaar
I do not see any explanation of what problem is caused by setting 'mouse' to "a".
jrodman-tcell
Selecting text does not work for purposes of copying. Clicking for purposes of pasting does not work.
Using the scrollwheel to access terminal history does not work.
shift-copying does not work either, though the idea that this should work is only based on some internet comments of how to workaround mouse=a problems. I'm not sure if that's supposed to work.
There are other more estoeric mouse-terminal interactions that do not work that I do not use often, I could do some research if you need more problems listed.
Realistically I tried out mouse=a around 1998, and though I found it cute, it interfered with too many day to day goals. Other people I've talked with have had the same experience. mouse=a has not improved to avoid these problems in the interim, and I generally recommend using gui vim as a way to avoid this problem when it's an option and mouse support is desired.
Here we are 20 years later, and mouse=a in terminals is still a thing that is still not practical, but now it's on by default, but the downsides have not been addressed (indeed, I doubt they can be).
Christian Brabandt
I think this is a duplicate of #2042
Richard Hartmann
the last weeks; the first time I installed new systems for years. As
those systems were not intended for personal use, I didn't copy my
personal configs which have carried anti-mouse boilerplate for roughly
a decade.
I was bitten by mouse being enabled on every one of those systems;
especially when setting up, it's quite common to copy & paste text,
data, and config over. For configs, I usually use Vim. Not being able
to paste by pressing middle button and having my cursor jump all over
the place was surprising at best.
On the other hand, I do get that new users might have an expectation
of the mouse working. But I would argue that those could use gVim if
they wanted a more mouse-centric UI.
Richard
vim-dev ML
lilydjwg
> As a random data point, I installed three new systems with Debian in
> the last weeks; the first time I installed new systems for years. As
> those systems were not intended for personal use, I didn't copy my
> personal configs which have carried anti-mouse boilerplate for roughly
> a decade.
>
> I was bitten by mouse being enabled on every one of those systems;
> especially when setting up, it's quite common to copy & paste text,
> data, and config over. For configs, I usually use Vim. Not being able
> to paste by pressing middle button and having my cursor jump all over
> the place was surprising at best.
support? I use mouse generally because it gives me better copy-n-paste
support (e.g. without line numbers nor linewraps). It works only with
an X connection though, but bracketed paste mode works as long as your
terminal and Vim support it.
(It would be great if terminals could accept copying with data given by
application too.)
> On the other hand, I do get that new users might have an expectation
> of the mouse working. But I would argue that those could use gVim if
> they wanted a more mouse-centric UI.
>
>
> Richard
Best regards,
lilydjwg
Linux Vim Python 我的博客:
https://blog.lilydjwg.me/
--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?
Bram Moolenaar
Using the shift key should work to get the terminal copy/paste behavior. If it doesn't then probably there is something wrong in your setup.
Note that if we would remove setting 'mouse' to "a" then we have a lot of other users complaining that the mouse doesn't work in Vim. It's impossible to guess what the user wants, thus we need to go for the majority, and it is unavoidable a few users will be unhappy.
—
You are receiving this because you commented.
jrodman-tcell
Vim is a real outlier here. Most terminal programs do not take over the mouse, so this newish behavior is failing principle of least surprise.
Then there are various problems.
- the mouse setting docs are not clear on how to turn off terminal mouse, "not a". Reading the docs leaves me without a clear idea how to turn it off. I think most people would want mouse support in gtk-vim or mac vim, but not terminal vim and it's unclear from the mouse settings if turning it to some other value would break gui vim support for the mouse
- The documentation states explicitly that "" is the default. Users who are not expert in what defaults.vim is will likely not understand that it defaults to something else, really.
- Checking the operating system defaults does not clarify the problem.
- Decades of time went by for people to get used to set mouse=a being an option to switch on, and the downsides of mouse=a have not changed in that time. For users to unpack how this came to be could take days of effort. (it did for me.)
- Editing the operating system default config to change the mouse setting doesn't work, which is highly mystifying. (I understand why now, but this was part of my journey to fix my vim install.)
- My operating system (debian) basically wants to give me the mouse experience that I want, which is no mouse=a, but they can't because the customization layering does not provide for this.
—
You are receiving this because you commented.
Bram Moolenaar
Most terminal programs use only line editing. Vim is a full screen editor, where using the mouse is expected to work. I get quite annoyed when I run into a setup where it doesn't work.
I really don't see how users can use Visual mode, resize windows and many other things without the mouse. And I see no reason to make disabling the mouse a better default. Just get used to using the shift key if you want to dumb and low level terminal copy/paste (which doesn't support block mode, doesn't fill a register and has many other disadvantages).
The help clearly states that 'mouse' is set to "a" in defaults.vim, with a link to more detailed help.
—
You are receiving this because you commented.
Bram Moolenaar
jrodman-tcell
You don't seem to be addressing any of the real problems. This looks like you're pushing your own preferences on the world.
FYI, in my environment tried shift, and it didn't work.
I used to consider nearly all software to be unreliable, but vim was one of the reliable ones.
—
You are receiving this because you commented.
Christian Brabandt
It's his project after all :)
I am failing to understand why you can't do :set mouse= and be done with it. After all, you most likely have probably already configured your vim, right?
—
You are receiving this because you commented.
jrodman-tcell
Since you asked, I already pointed out this means that every time I ssh into a system, jump into a container, etc, selecting text with the mouse doesn't work. You're suggesting that i put a config file into the world. Happy to drop it at this point, but willing to answer any questions.
—
You are receiving this because you commented.
Eric Pruitt
I don't have strong opinions about the default setting of "mouse", but I want to address this comment:
I really don't see how users can use Visual mode [...] without the mouse.
I use terminal Vim exclusively without mouse support enabled, and I use visual mode practically every day. I typically use "/" or "?" to move to the beginning of the text I want to select, use another search command to move the cursor to the end of the text I want to select then use something like V'' if I want to select a series of lines or v`` if I want a more granular selection.
—
You are receiving this because you commented.
K.Takata
this means that every time I ssh into a system, jump into a container, etc, selecting text with the mouse doesn't work.
How about changing the setting of your terminal? E.g.:
- Disable mouse tracking
- Set
$TERM=vt100 - Use a terminal which doesn't support mouse tracking
No need to set every system.
—
You are receiving this because you commented.
chdiza
I really don't see how users can use Visual mode [...] without the mouse.
With the keyboard (mostly motions and text-objects). I thought that was the whole point of visual mode---to be able to make selections while keeping your hands on the keyboard.
—
You are receiving this because you commented.
boltronics
When I upgraded my servers to Stretch I ran into this. I agree this is a horrible default when running Vim over an SSH session and the change really should be reverted.
A typical use case for me is to double-click a word to highlight it, hold down shift and single click another word, which would also highlight the complete second word and everything in between. This works everywhere except (as of this commit) in Vim. @brammool The option to hold down shift no longer works for this use case at all, so as far as I am concerned Vim is now shipping a broken default and no longer covers my simple use case. Unfortunately this made it into Stretch and likely won't be fixed until all servers are upgraded to Buster, meaning this problem will persist for many years to come even if patched today.
For everyone else who just wants a good, tiny text editor with working mouse support and syntax highlighting to quickly edit a file on any random server they might need to access (ie. without a custom user configuration), JOE and Nano continue to work just fine and are also actively maintained and available seemingly everywhere.
—
You are receiving this because you commented.
msmith3-uottawa-ca
Just got bitten by this working over SSH. What a pain in the rear.
Most terminal programs use only line editing. Vim is a full screen editor, where using the mouse is expected to work.
This doesn't seem accurate to me, at all. The utility of vim is 99% in its use over SSH, where I DO expect it to act the same way as every other terminal program.
—
You are receiving this because you commented.
TechRiggs
You don't seem to be addressing any of the real problems. This looks like you're pushing your own preferences on the world.
This seems to be the case here. Another +1 for running into this problem on a fresh install.
Right-Click to paste had always worked, until now. Knowing to hold SHIFT while you're in the middle of setting up large configs in a brand new environment is not something you would expect to know after years of never having to do it before.
I have read through the multiple issues on this project relating to configs and their defaults. There's a lot. And on each and every one of them, @brammool dismisses and promptly closes them all with essentially an "I don't care" attitude. Shame.
Again, I couldn't agree more with the following statement:
You don't seem to be addressing any of the real problems. This looks like you're pushing your own preferences on the world.
But, granted:
It's his project after all :)
However, this begs the question... How much noise has been generated by this new default? Is it worth the headache?
I'm confident if the "old" default behavior is brought back, the noise would go away.
—
You are receiving this because you commented.
Bram Moolenaar
Unfortunately Vim cannot possibly guess what the user wants.
If the default is to not enable the mouse, then all users that expect it to work will complain. Or they might not even know the mouse could work if they enabled it. Or they don't even know how to enable it, since otherwise it always just works.
If the default is to enable the mouse then users who expect a different behavior will complain. But they have an easy way to do ":set mouse=" and the problem is gone. Thus it's a minor inconvenience.
Now some may argue that the current behavior gives rise to complaints. Sure. But if the default is the other way around then another group of users will complain (or think Vim is broken, if they don't know the mouse would actually work if they enable it). It is my opinion that there are more users who want to use the mouse then users that don't want to use the mouse. On top of that, since the fix is easy, defaulting to enabling the mouse is the right choice.
—
You are receiving this because you commented.
boltronics
If the default is to enable the mouse then users who expect a different behavior will complain. But they have an easy way to do ":set mouse=" and the problem is gone. Thus it's a minor inconvenience.
The problem is for users who regularly SSH into many machines and need a text editor on them, for which this change cannot work. Unless they are all set up through configuration management under your control, in advance of connecting, every new machine will be using the defaults, so it might be impractical to set a configuration for every machine.
Worse still, some machine will use old versions of Vim, and some will use newer versions of them. The user experience is no longer consistent.
People who want the mouse to work are most likely to be people running Vim locally. They are more likely to only have one computer to configure, so it is far easier for those people to manually change the mouse behaviour if they so desire. That is why the default is now wrong.
FWIW, I'm actually an Emacs user primarily. I have the version on my local computer heavily customised to work exactly the way I like it (as I imagine most Vim users would). When I find myself SSHed into another machine (I wasn't initially using TRAMP from my local host) but also notice emacs installed on that destination host, I generally use Vim instead - because the defaults have always made more sense. For example, Vim doesn't create a file~ backup in the local directory automatically which can cause problems if editing some configuration files in specific directories. Vim by default shows you the row count without needing to run a command to show it. etc. Vim was the last good editor for this use case, but that is the case no longer.
—
You are receiving this because you commented.
K.Takata
I don't have strong opinion about this, but it seems that Bram doesn't want to change this setting anymore.
The problem is for users who regularly SSH into many machines
As I wrote above, you don't need to change the setting in every machine. You just need to disable mouse tracking in your terminal emulator.
—
You are receiving this because you commented.
boltronics
As I wrote above, you don't need to change the setting in every machine. You just need to disable mouse tracking in your terminal emulator.
Emulating vt100 doesn't help - it just makes things worse! For example, that breaks syntax highlighting. I think most people would agree that not having syntax highlighting is even worse than the mouse not working correctly.
However if there is some option in terminator that does what you mean, please let me know. I couldn't find anything that sounds like what you are describing and I've been using this terminal emulator for many years, so assuming such a feature doesn't exist.
Perhaps it would make more sense for Vim to have the default mouse setting changed only when Vim developers have upstreamed patches for all terminal emulators people are currently using to run it?
Alternatively, Vim might only have the mouse activated when in GUI mode (so it doesn't impact people running it in terminal emulators)? Aside from some edge cases such as elinks or dpkg-reconfigure menus that are primarily applications full of buttons/links, I question if people using a terminal emulator ever normally expect an application to alter mouse behaviour by default? I would be surprised if they did.
—
You are receiving this because you commented.
TechRiggs
Unfortunately Vim cannot possibly guess what the user wants.
Again, there is no guess work required. Read this thread. We don't want mouse=a as a default. Put it back the way it was, please.
an easy way to do ":set mouse=" and the problem is gone. Thus it's a minor inconvenience.
Not a minor inconvenience when SSHing into many servers. It's a major inconvenience.
It is my opinion that there are more users who want to use the mouse then users that don't want to use the mouse.
*facepalm*
Why are you forcing you opinion onto the rest of the world? How did you come about this opinion? Do you have any data to support your opinion??
Opinions are like sphincters. Everyone has one!
since the fix is easy, defaulting to enabling the mouse is the right choice.
So you are admitting that we need to fix the new default. You may be shocked to hear that we never needed to fix the default config before.
It's not the right choice. It's your biased opinion. The right choice is to listen to your user base.
@brammool, Since you are a developer, it makes sense that you like to have the mouse enabled. I get it. You work on a local machine rarely needing to ssh and use vim on a remote machine. For those of us in the System Administration world, we use vim over ssh on a daily basis.
Since your fix is quite simple by running :set mouse=a on your laptop, could you please turn it off for the rest of the planet who doesn't use it?
If the rest of the world do actually use it, and we are the minority, please provide factual data.
Opinions don't count.
I want to continue liking vim. I want to keep showing new linux sysadmins how good vim is. Please don't make me look for a different product... Please.
Hear Us.
—
You are receiving this because you commented.
Dylan McClure
> Defaulting on the terminal mouse via defaults.vim breaks many expected behaviors, and should not be on by default, even when there is no .vimrc present.
>
> In addition, this setting should lose to other settings in /etc if they express an alternate value that conflicts with the one in defaults.vim
>
> Vim has a very long history of being conservative and reliable. I have generally trusted vim. This setting is far too aggressive. Today it has caused significant lost productivity, and there is no clear path towards resolving this for the future across the many environments where I will encounter vim. I cannot readily automate installing sanity on every image, vm, os, docker image, etc where I might expect vim to execute in the future.
>
> I will not be surprised if this is a dupe, but I made a good faith effort to search for past issues, open or closed before creating it, and I feel it is a real and serious regression in vim behavior.
>
>
> —
1. No one wants mouse=a as default (think about vim philosophy and user base)
2. It makes more sense to leave as mouse= (this is the default right now, right?)
It's just as easy to put mouse= as mouse=a in vimrc, but mouse= as default makes more sense.
Octavio Alvarez
- Disable mouse tracking
I actually like this idea, as I want don't want my mouse to do weird stuff. I want my clipboard to work as it always have been. But I don't know how and a Google search got me nowhere. I might search later. I found some difficult solutions.
After stating the above, I feel compelled to question the reasoning for changing the behavior, as it is biased in two ways:
Note that if we would remove setting 'mouse' to "a" then we have a lot of other users complaining that the mouse doesn't work in Vim. It's impossible to guess what the user wants, thus we need to go for the majority, and it is unavoidable a few users will be unhappy.
How did you conclude that this is the majority? The point is: you won't get complaints from people for which Vim works well before you break things. Thus, your perception will be that the majority wanted mouse, which might as well not be the case.
By the same logic, your mouse-happy users will start to fade away because they will stop being vocal enough (because now it works how they want); now, we, who want the previous behavior back, are now the more vocal group and are now the majority. This implies you will bring back the old default. Your defaults will start to oscillate under this way of reasoning.
The problem is that mouse-unhappy users were never going to be vocal on time because we never knew a change like this was going to occur. We don't monitor each and every project to understand its commits and future. So it's unfair to the existing user base to think like this.
If the default is to enable the mouse then users who expect a different behavior will complain. But they have an easy way to do ":set mouse=" and the problem is gone. Thus it's a minor inconvenience.
This is the second bias: The minor inconvenience is exactly the same for people who wanted the mouse function. So, I propose a counterargument of mine: people who want the mouse have an easy way to do ":set mouse=a" and the problem is gone. Thus it's a minor inconvenience. Now your argument and mine are exactly the same.
I will just start looking for workarounds. This does not diminishes how much I appreciate Vim. Think of my comment as just a minor inconvenience. :-)
—
You are receiving this because you commented.
emmandyar
So, this is a case of a dev going all Gnome on it's user base. Gotcha.
The "easy fix" would be something like
echo "set mouse-=a" >~/.vimrc
use '>>' instead of '>' if you already have a customized vimrc
Christian Brabandt
If you already have a personal vimrc, than it is no problem.
Tony Mechelynck
The utility of vim is 99% in its use over SSH, […]
Again, there is no guess work required. Read this thread. We don't want mouse=a as a default.
Since you are a developer, it makes sense that you like to have the mouse enabled. I get it. You work on a local machine rarely needing to ssh and use vim on a remote machine. For those of us in the System Administration world, we use vim over ssh on a daily basis.
Well, I'm neither a developer nor a sysadmin but a plain user, I never use SSH, and I want my mouse clicks to go to Vim and not to some dumb terminal, if at all possible, when I'm running Vim in a console terminal, so I get the same experience, or as close as possible, when using vim or gvim. So I'm giving the lie to all the quotes above, and yet I don't think I'm the only one of my kind, far from it. But I've had a vimrc since shortly after I started using Vim, which was long before defaults.vim came into being. Why don't you? No two people have exactly the same preferences: we're humans, not Panurge's muttons, after all (BTW, those particular muttons were sheep, actually, but at a time when the English upper class read Rabelais in the French original, hence the phrase "let's go back to our muttons"), thank $DEITY, and that's what the vimrc is for: You don't like the defaults? No problem, write your own settings into a vimrc, and voilà! Problem solved.
boltronics
@tonymec If you don't use SSH, you probably have very few boxes you use Vim on. If you did use SSH to access remote servers from a pool of tens or perhaps hundreds of boxes possibly running different distributions with different versions of Vim, you would know that you no longer get a consistent experience.
The only option is to use configuration management to change the defaults for your user account on all these machines (which in some workplaces might be difficult where unnecessary customisation is frowned upon), or to remember to run :set mouse= every single time you launch the editor.
Tony Mechelynck
If I did, I would upload my vimrc somewhere on the Net, and download that into my user's home directory when changed (which isn't often). Yeah, version management is one option but not the only one. And if some admin wanted my home directory to be unwritable by me, he'd get my resignation slip fast.
boltronics
I never said home directories are unwritable, but you're not going to just upload configuration files "somewhere on the Net" and expect to be able to access them in a production environment. There will be firewall rules, security policies, etc - just as there should be! You're not going to use a "USB chip" if you never have access to the physical hardware.
So yeah, if there actually were some practical solution other than those frustrating ones I've already listed, I'd love to hear it. I'm all ears.
Christian Brabandt
alias vim=vim -c set mouse=
h_east
alias vim=vim -c set mouse=
This should be alias vim='vim -c "set mouse="'
Or, set the environment variable VIMINIT as follows.
$ export VIMINIT="set mouse="
boltronics
Unfortunately I don't think the alias option is helpful over SSH, unless it's typed each time one connects to a remote box or is already deployed on each box (in which case, it would be no different from deploying a vimrc file).
The environment variable approach is more interesting. This would be great if the sshd_config setting PermitUserEnvironment was enabled by default or if it were added to AcceptEnv by default, but unfortunately it's not.
It's perhaps more reasonable to have this added to the AcceptEnv list on the servers we manage via configuration management (so we don't need to have per-user configuration preferences deployed everywhere). I guess that's as good as we can expect while the change to the mouse default exists, but it's far from perfect since each host still needs to be configured in advance.
At least the servers don't need per-user configuration changes, but individual users can still set VIMINIT locally as they wish (however they'll all have to update their ~/.ssh/config file also).
Yee Cheng Chin
As Bram said, no matter what defaults Vim picks, it would annoy some users. Every default option is ultimately an opinion that the developer forces upon its users. Someone has to make a choice. You could always fork it.
There are already a lot of suggestions on how to alleviate this issue, but I'm kind of curious why people need to SSH into dozens of machines just to use vanilla Vim without any vimrc on them? I would assume you should mostly be deploying files to production servers, not to SSH into each one just to edit individual config files. Vim also supports editing files over scp, so you could be on a machine and edit files remotely, with all your customized vimrc on the local computer. A lot of terminals also do support shift-mouse-drag to select text (which I actually find really useful for using tmux with mouse mode on actually). Or you could always alias ssh to automatically map the vim command to start with clearing the mouse flag too if you so wish.
boltronics
As Bram said, no matter what defaults Vim picks, it would annoy some users.
@ychin Except the users with some use cases are inconvenienced significantly more than others. Sure, it's not my project and I don't have any right to demand vim not mess with my mouse by default, but that doesn't prevent me from expressing my opinion or concerns.
I would assume you should mostly be deploying files to production servers
It is unfortunate so many assumptions have been made.
A recent example would be the issues over the last few months with the Linux kernel when running Xen paravirutal guests, and needing to run experiments with different boot arguments to get things working again. There have been issues in the past with the Debian Asterisk packages breaking some use cases where the server is using specific hardware and package pinning files needed to be adjusted.
When you have a significant number of servers to support that all run different software, things are going to go wrong and you're going to have to shell in and fix issues - which usually involves editing files with elevated privileges.
You may also have a bunch of machines that run non-critical services (such as an internal wiki, bug tracking software, inventory management software, etc.) that we don't have test infrastructure for, so in such cases configuration changes (Apache, PHP, etc.) need to be made and tested on the actual server before having changes migrated to configuration management.
Vim also supports editing files over scp, so you could be on a machine and edit files remotely
If you're already needing to be on the remote machine to run sudo update-grub, restart services, check logs, etc. it makes sense to use the editor already on the remote host as you already have a shell open there. Besides, none of our machines allow users to connect via SSH directly as root as per security policies, but editing such configuration files require root privileges.
Now if I wanted to do this, I could already do it with Emacs using TRAMP (and I do on occasion) - which even supports privilege escalation via sudo - but again I don't want to do that. It can be frustratingly slow when connecting to hosts on the other side of the world (where most of the hosts I manage are) and again - I already have a shell on the host I want to edit the file on.
A lot of terminals also do support shift-mouse-drag to select text
More error prone but nowhere near as efficient as double clicking anywhere within the first word, holding shift, and double clicking anywhere within the last word in a block (which I've been able to do without issue for as far back as I can remember in GNU/Linux) - especially when using a small font to maximise screen real estate. Doing that may now open visual mode and prevents Ctrl+Shift+C from even copying anything! Much of this issue is the inconsistent behaviour between machines we now face when performing simple mouse actions.
Or you could always alias ssh to automatically map the vim command to start with clearing the mouse flag too if you so wish.
I don't want the vim command to automatically start when I SSH into a remote host, if that's what you mean. I want to troubleshoot an issue, and edit files in a small vim installation (that most likely require privilege elevation via sudo) when I need to, and be able to copy and paste text between other shells and applications in a working and consistent manner. That's the use case.
For now I have AcceptEnv LANG LC_* VIMINIT in /etc/ssh/sshd_config which is deployed via configuration management, and I have SendEnv VIMINIT for all hosts in my ~/.ssh/config file, and I have export VIMINIT='set mouse=' loaded from my ~/.profile. This turned out to be an acceptable work-around for me for now. Much thanks to @chrisbra and @h-east for the tip.
Daniel Hahler
in
/etc/ssh/sshd_config
-
You could also deploy a defaults.vim probably, setting "mouse=" there, similar to what ":h defaults.vim" suggests for a user config:
unlet! skip_defaults_vim
source $VIMRUNTIME/defaults.vim
set mouse=
Or even better just a /etc/vimrc where you "let skip_defaults_vim=1".
-
Also I wonder with which terminals using Shift to bypass this does not work? Should be reported / fixed with them then probably.
-
I am using "mouse=nvi" myself, but often use Shift instead of Vim's own selection - I guess I have it mainly for going quickly to some position in another window.
-
Neovim has "mouse=" by default.. ;)
-
I agree that "mouse=" would be a better default (especially since "mouse=a" in a custom config is easy), but I also think that ":set mouse=" is easy enough if you know that you're going to use the mouse and using Shift to bypass does not work.
Distributions meant for servers could actually also provide this for their users.
boltronics
-
Possible. It's also possible that another sysadmin joins the team and hates that preference, and then we're back to per-user preferences needing to be deployed everywhere, which we have observed can quickly get out of control the minute that is allowed, and hence we want to avoid.
-
You can shift and drag (which I find extremely difficult on my laptop's 13" 4k screen when using a touchpad). You can't shift and double-click, which is what I've been doing for many years and is far easier from a usability viewpoint, even with larger fonts and a mouse. Double-clicking anywhere within a word gives you a much greater space to position the cursor instead of trying to get the cursor right between two specific characters.
-
If Neovim were installed by default on any GNU/Linux distribution and release we manage, I would have no issue in using that. 😃
-
As a user in a shell, I'm potentially jumping into and out of vim sessions quite a lot. For example, right this moment I'm tweaking a build system on a remote host over SSH. I'm making tweaks to JSON in vim, exiting out to re-run the build commands and watch the output, jumping back into vim to edit configuration files, etc. until all the issues are resolved.
This build machine will be around for a few hours and then decommissioned so needing to make persistent changes to it every day I need to do this would be annoying, but probably less so than having to typevim<enter>:set mouse=<enter>every time to open the editor in case I end up using the clipboard and forget (which happens quite a bit if I don't take care of it at launch).
Anyway, I've got that VIMINIT hack now so that's as good as I can see this getting, but it is still a PITA on occasion when I need to switch to a different user, edit files and get hit by this issue again.
Daniel Hahler
I see, glad you got it solved for you.
As a user in a shell, I'm potentially jumping into and out of vim sessions quite a lot.
Try Ctrl-z and fg instead. (I've also mapped Ctrl-z in my shell to do fg automatically / not spam the history, but fg is really short enough ;)).
Also of course there is :! if you do not want to leave/quit Vim (although you do not have the full shell there obviously).
boltronics
Good point. Ctrl-z and fg would work for me in most cases. Something I have to get used to. 😄 Thanks.
scoopgracie
This setting makes it extremely difficult to copy and paste between vim in a terminal emulator and other desktop apps. It makes absolutely no sense to force users to change a setting for this crucial feature. Make it an option, but have it off by default and make it show a dialog asking if you are absolutely sure you want to break copy and paste before enabling it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
scoopgracie
External copy and paste is far more important that mouse support in a command-line editor. The whole reason anyone uses the command line is to avoid the mouse.
Bram Moolenaar
Everybody can have their opinion. In the mean time the default has become "nvi". This means you can type a colon, copy the text, and Esc to go back. It's the best compromise, I use it regularly in the Mac terminal. I would not want to do without the mouse, e.g. for resizing a window.
scoopgracie
On Wed, Dec 11, 2019 at 1:47 PM Bram Moolenaar <notifi...@github.com>
wrote:
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AN54XP74WHUHEVIIIGO5Q3DQYFNYVANCNFSM4E4JFZGQ>
Velkan
When you want this mouse then you edit the vimrc and enable it on your machine.
When you a system administrator you don't want mouse in vim and you've got boxes with the default vim. So the default must be mouse disabled.
Is this that hard to understand?
limepanda
I am leaving vim because of this change of behavior! I was forced to search on the internet which led me here. What a waste of time for so many loyal users just for this tiny yet huge change! Sad!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
Alex von Gluck IV
Just joining the choir of people hating the new mouse mode default.
I log into tens of Linux machines daily, and copy and paste data between them. Having to :mouse= each and every time I open vim drains so much of my damn day.
The big issue with mouse mode is I expect pastes to go where my cursor is.. not where the mouse is. vim is a terminal application. xvim can do whatever it wants.
Honestly, this change has been the single worst thing for my productivity in decades. I spend a lot of time in vim on a hugw number of systems. I'm having to spray vimrc files everywhere to keep from accidentally distroying sensitive bind zone records with paste data.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.
Ben Jackson
Hold shift?
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.
Adam Bolte
@puremourning Please read the above posts. There are many situations where that doesn't help.
Honestly, this change has been the single worst thing for my productivity in decades. I spend a lot of time in vim on a huge number of systems.
I feel exactly the same way.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Alex von Gluck IV
I just starting installing neovim (neovim.io) on every system I can find. It disables mouse integration by default and offers some compelling features.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
The default "mouse=a" is only used for xterm, where you can use the shift key to select text directly.
Otherwise "mouse=nvi" is used, in which case you can press ":" to go to the command line and then select text.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Alex von Gluck IV
The default "mouse=a" is only used for xterm,
Most terminals report xterm.. so this is pretty irrelevant.
Here's gnome term under wayland for example:
gnome-terminal for example:
$ echo $TERM
xterm-256color
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
then simply set $TERM=foobar in your bash_profile
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Velkan
then simply set $TERM=foobar in your bash_profile
I repeat:
When you are a developer and want a fancy mouse then you set it up in your custom profiles.
If you a system administrator then you don't want mouse in vim and you've got boxes with a default vim. So the default must be mouse disabled.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
Funny thing is: I changed roles some time ago and have to jump on a lot of client boxes and configure software modules using vi. And most clients use just putty to connect to the remote linux box. And I have never come across that particular annoyance, even without configuring vimrc. :set mouse was just not an issue there (and even it it was, I could simply use and alias or would configure $TERM to something different or use the mentioned shift approach when copy-pasting).
If you a system administrator then you don't want mouse in vim and you've got boxes with a default vim. So the default must be mouse disabled.
I am not sure what is different in your environment, but for me this is not true.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Velkan
@chrisbra it's objectively worse than before, plus it's wasting time talking about it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
If your $TERM says "xterm" then it should behave like an xterm. How else can Vim know how your terminal behaves?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Alex von Gluck IV
The whole point of this is the default to mouse=a means the following:
- If you're a developer, and mouse mode is important within a terminal application, you have to :mouse=a one one system.
- If you're a sysadmin managing hundreds of systems, and mouse mode drives you utterly bonkers breaking text pasting as reported pretty much everywhere (just google vim mouse sucks), you have to type
:set mouse=-ain every document you edit on every system you work on, or put a vimrc in place across every system you manage in every user account you use (non-root, root, etc).
So the convince of a few desktop users outweigh the sanity of anyone using vim on 100's of systems and containers.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Dominique Pellé
@ChipmunkV wrote:
If you a system administrator then you don't want mouse in vim and you've got boxes with a default vim. So the default must be mouse disabled.
The same could be said for system administrators who prefer the mouse enabled by default. Having it by default allows them to resize windows etc. So I don't think it's a valid argument. In fact, since you can use shift to prevent vim handling the mouse, it's more versatile if it enabled by default.
Every default setting is debatable, but if a default makes 90% if users happier, it seems like a win.
Now for sys admins that need to login to many boxes without ~/.vimrc on each box and who don't want the mouse, I don't really know how to set up their preference. Maybe they should just start vim like this vim +'set mouse=.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
> The whole point of this is the default to mouse=a means the following:
>
system"? That is very rare, most people use Vim on multiple systems.
> * If you're a sysadmin managing hundreds of systems, and mouse mode
> much everywhere (just google vim mouse sucks),
Or use the scrollwheel. Or make a Visual selection with the mouse.
I think you are only saying "this change broke my habits and I can't
possibly change my habits".
> you have to type ```:set mouse=-a``` in every document you edit on
> every system you work on, or put a vimrc in place across every system
> you manage in every user account you use (non-root, root, etc).
key configured instead of typing "vim /etc/some/config" so many times,
right? So you can just make it "vim -u NONE /etc/some/config".
> So the convince of a few desktop users outweigh the sanity of anyone
> using vim on 100's of systems and containers.
tools being used, thus has lots of ways to configure those tools to their
needs. While beginners start Vim and say "it doesn't even support the
mouse!", not knowing even the ":set" command, and switch to Notepad or
something.
--
FIRST GUARD: Ah! Now ... we're not allowed to ...
SIR LAUNCELOT runs him through, grabs his spear and stabs the other
guard who collapses in a heap. Hiccoughs quietly.
"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/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Christian Brabandt
If you're a sysadmin managing hundreds of systems, and mouse mode drives you utterly bonkers breaking text pasting as reported pretty much everywhere (just google vim mouse sucks), you have to type :set mouse=-a in every document you edit on every system you work on, or put a vimrc in place across every system you manage in every user account you use (non-root, root, etc).
I was about to write a cynical comment, but I figured it may be much more helpful to actually be constructive here :)
So would the following help:
- Only
:set mouse=aif a real xterm is used (by parsing thev:termresponsevalue and setting this value only for xterms > 266 which was released around 2010 - Leave the mouse setting alone if an environment variable
$VIM_DO_NOT_TOUCH_THE_MOUSEexists
This way you could set in your environment export VIM_DO_NOT_TOUCH_THE_MOUSE=1 and vim will no set the mouse option at all. Not sure if this helps, you would still have to configure your environment to add that variable there of course.
Something like this in a patch:
diff --git a/runtime/defaults.vim b/runtime/defaults.vim index f1d5cd1ed..577d54602 100644 --- a/runtime/defaults.vim +++ b/runtime/defaults.vim @@ -78,12 +78,9 @@ inoremap <C-U> <C-G>u<C-U> " can position the cursor, Visually select and scroll with the mouse. " Only xterm can grab the mouse events when using the shift key, for other " terminals use ":", select text and press Esc. -if has('mouse') - if &term =~ 'xterm' - set mouse=a - else - set mouse=nvi - endif +if has('mouse') && exists("$VIM_DO_NOT_TOUCH_THE_MOUSE") + set mouse= + " Rest will be handled in <sid>SetMouse() endif " Only do this part when Vim was compiled with the +eval feature. @@ -124,6 +121,27 @@ if 1 \ echohl None augroup END + augroup VimTermResponse + au! + autocmd TermResponse * call <sid>SetMouse() + augroup END + + function! <sid>SetMouse() + if exists("$VIM_DO_NOT_TOUCH_THE_MOUSE") + return + elseif has("mouse") && &term =~ 'xterm' + " Try to match xterms specific Terminal Identifier and only set the + " mouse=a if we are sure, that this is an actual xterm (version > 266) + let termresponse = matchlist(v:termresponse, '\(' .. "\e" .. '[>\d\+\);\(\d\+\);\(\dc\)') + if len(termresponse) > 2 && (termresponse[2]+0) > 266 + set mouse=a + else + set mouse=nvi + endif + else + set mouse=nvi + endif + endfu endif " Switch syntax highlighting on when the terminal has colors or when using the
This obviously would need some documentation and perhaps the setmouse function can be made even more bulletproof.
Or perhaps I am just over-engineering this whole thing 🤷♂️
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Alex von Gluck IV
I was about to write a cynical comment, but I figured it may be much more helpful to actually be constructive here :)
I mean, my constructive position is was what improvement does mouse + clipboard interaction offer?
This all feels like when Gnome 3 decided to make the delete key "not delete files" in file manager because there were a few user complaints it was too easy to delete files. Gnome didn't document this change, and didn't document what key bindings to hit to actually delete files. After around 50 - 100 bug reports of being unable to delete files rolled in over a few years, we were able to finally tie them together to make a case about how dumb of a change was.
I honestly feel like this fits the same profile. A change for change's sake with no real improvement to UX. I've personally two different hardened sysadmins at work complain about the "broken paste" in vim, and ran into a new linux / vim user asking how to paste where his cursor was while in insert mode.
It's kind of frustrating from all sides. Do a quick search for "vim disable mouse paste" and you get a million results of people trying to figure out how to turn this off:
https://www.google.com/search?q=vim+disable+mouse+paste
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Dominique Pellé
@kallisti5 wrote:
It's kind of frustrating from all sides. Do a quick search for "vim disable mouse paste" and you get a million results of people trying to figure out how to turn this off
https://www.google.com/search?q=vim+disable+mouse+paste
It seems exaggerated:
- people who don't like the new mouse setting will post, but people who like it stay silent. So it's biased.
- many (or most) of the Google results are unrelated to the default
mousesetting. Google has become so bad that it annoyingly ignores some of the words in the query.
I'm really not sure that most users prefer the mouse disabled rather than enabled. I suspect most prefer the mouse enabled, especially when it's easy to use shift to have the behavior you want.
In any case, you can't satisfy everybody here, so I don't see a way to resolve it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
Alex von Gluck wrote:
> > I was about to write a cynical comment, but I figured it may be much
> > more helpful to actually be constructive here :)
>
> I mean, my constructive position is was what improvement does mouse +
> clipboard interaction offer?
the scrollwheel and do Visual selection with the mouse. Doing that with
the keyboard takes much more time.
> This all feels like when Gnome 3 decided to make the delete key "not
> delete files" in file manager because there were a few user complaints
> it was too easy to delete files. Gnome didn't document this change,
> and didn't document what key bindings to hit to actually delete files.
> After around 50 - 100 bug reports of being unable to delete files
> rolled in over a few years, we were able to finally tie them together
> to make a case about how dumb of a change was.
> I honestly feel like this fits the same profile.
accidentally press the wrong key, instead of making that key do nothing
or put up an annoying dialog, there should be a way to revert the
action. I do not see a relation with a not working mouse.
> A change for change's sake with no real improvement to UX.
> I've personally two different hardened sysadmins at work complain
> about the "broken paste" in vim,
the mouse is often used for pasting (typing "+p also works though). Can
you be specific about what you are referring to?
> and ran into a new linux / vim user asking how to paste where his
> cursor was while in insert mode.
Unless the user comes from MS-Windows, then CTRL-V would do it, but you
need to configure Vim for that.
> It's kind of frustrating from all sides. Do a quick search for "vim
> disable mouse paste" and you get a million results of people trying to
> figure out how to turn this off:
FATHER: Did you kill all those guards?
LAUNCELOT: Yes ... I'm very sorry ...
FATHER: They cost fifty pounds each!
emmandyar
IMHO, there's no point in trying to revert the change now (nor continue arguing). It had been 4-ish years since the issue surfaced with the new batch of distros releases and at that point it made sense to argue, the change was somewhat recent and the old users, who found the change disruptive, were far more than the new ones, who find it normal behaviour.
Nowadays, at least in my case, it has become part of my setup new server routine to enter vim and ':set mouse =', with the occasional curse towards vim devs in general for the (not the actual word I use) stupid setting when I forget to issue the command.
Besides that, the issue was closed and no revert ever happened
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
kees-closed
Even more advanced TUI programs don't make use of a mouse. vim defaulting to mouse select really breaks consistency in my terminal's behavior. At first I thought it was a silly Debian default set somewhere, luckily my Fedora workstation still uses a sane configuration.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Iftikhar Rathore
I agree, kill the beast, we dont want this feature.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Alex von Gluck IV
IMHO, there's no point in trying to revert the change now (nor continue arguing). It had been 4-ish years since the issue surfaced with the new batch of distros releases and at that point it made sense to argue, the change was somewhat recent and the old users, who found the change disruptive, were far more than the new ones, who find it normal behaviour.
I disagree on this. You're starting to find frustrated sysadmins who manage hundreds of systems as the default of mouse=a sneaks onto "stable" distros that have a long gap between upstream changes and os releases. It's not reasonable to expect us to disable the mouse across hundreds of systems.
It's also not reasonable to ask anyone working in containers to disable vim mouse mode across every container they need to exec into. vim mouse mode doesn't not work properly in kubectl exec -it and most other container stdio environments. It's a constant struggle disabling the broken mouse + clipboard interactions everywhere
Stop catering to the loudest users instead of catering to the seasoned professionals.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Samuel Sloniker
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
emmandyar
Stop catering to the loudest users instead of catering to the seasoned professionals who get paid to keep the internet and servers everywhere running.
But we (who complains about this change) are the loudest users, you barely see any supoorter of this setting on here. My point was they didin't revert it at the moment, they won't do it now that YEARS have passed.
If you use ansible, you can set up vim with the rest of the server and get rid of the awful mouse handling from the very begining
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Lex English
I know it's beating a dead horse, but this is a daily frustration for me. This seems like a terrible default. Isn't one of the biggest points of vim that you can navigate and operate efficiently without the mouse? Shouldn't vim act like just about every other terminal application and leave mouse selection, middle click, etc., to the user's terminal emulator?
I see two problems with the argument that new users expect the mouse to work - A) I don't think they do, if they're running vim in a terminal it seems very unintuitive that they would expect to use the mouse there when very few other applications utilize the mouse there. And I don't remember encountering any vim materials training newcomers to use a mouse. B) It seems like this is catering to the wrong crowd. New users already tend to spend a ton of time just figuring out how to exit, such is the way with a powerful tool; but they can't be troubled to look up how to enable the mouse if they want it? And how many new users are likely to be logging into lots of systems that they don't have a custom config on or using containers that come with the default?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
xandro0777
The "new" default is completely useless for anyone because users won't notice any change other than that copy&paste is horribly broken unless they read manuals or changelog. Changes that can have catastrophic consequences without any warning should not be default.
What a glorious nonsense. Even most pure GUI apps still support copy&paste with mouse middle button because for many users it is more convenient than reading man pages.
I have started using vim in the 90ties when it was a sane alternative to all the vendor specific flavors that often weren't even capable of using those funky arrow keys on newish terminals. Well today there are enough other vi clones that work for everything I need. Good bye vim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christopher Plewright
Vim continues to evolve and move forward.
What if something like this also becomes the default for Vim?
set clipboard^=unnamed,unnamedplus
Wouldn't this solve more problems for most users?
I'm assuming that this would restore the expected functionality for what the new default mouse setting has removed from users - at least it would work in a number of scenarios that I can think of.
Since changing the long-standing default of vim to set mouse=a, was a step toward vim fitting in with current expectations, then wouldn't it also make sense if vim also changed the default setting of the unnamed register to use the system clipboard (if available) as well?
I imagine that the sorts of users who care about a change to the default of the unnamed register, might typically be capable of reverting the clipboard configuration quite easily. More easily than it is for the sorts of users who are impacted by what the change of the default mouse setting.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Alex von Gluck IV
@zewpo that doesn't solve anything for me.
- Open vim document with default mouse mode
- set clipboard^=unnamed,unnamedplus
- Scroll wheel click to paste selection buffer
- Newline pasted, no text added.
- p , no data pasted
- right click, cursor moves
Still frustrating, unable to paste lol.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christopher Plewright
I wonder if it is related to how your system clipboard is configured in your session.
Also, is your vim running on the same system, or you ssh or tmux or somewhere in there?
Admittedly I don't have a middle button to click.
Just checking. It works for me in xterm, kitty, xfce4-terminal, terminator, windows console command prompt, and the new windows terminal.
-
copy some text from web browser
-
open a terminal, eg xterm and run;
vim --clean -U NONE +"set mouse=a clipboard^=unnamed,unnamedplus" -
just type p
p -
see what happens
For me, I see that it correctly pastes all the text that I previously copied from my browser. -
In vim, with mouse, select some text that was just pasted,
-
copy (yank) that text
y -
open another terminal, say xfce4-terminator
-
open vim in the second terminal
vim --clean -U NONE +"set mouse=a clipboard^=unnamed,unnamedplus" -
paste what you copied from the first terminal
p -
see it pastes correctly what I copied from the other instance of vim.
-
open up some random text, eg open help
h: -
select some random text from the middle of the help text.
-
copy (yank) that text
-
open gedit
-
paste into gedit, (eg ctrl-v)
-
see that it pastes exactly what I yanked from vim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Alex von Gluck IV
I wonder if it is related to how your system clipboard is configured in your session.
Default configuration.
Also, is your vim running on the same system, or you ssh or tmux or somewhere in there?
Same system, or other system via ssh. Same behaviour
- Done
- Done
- Done
4.a Highlight clipboard. Highlight text. p to paste in vim. E353: Nothing in register ''
4.b I copy text in Opera (by actually clicking copy). Highlight and do a full copy.. press p in vim E353: Nothing in register '' - I never do this. Just yy, y1l, y1w, etc.
- etc
As I mentioned, using the selection clipboard. You don't have to copy and paste in Linux, just highlighting text puts it into your "selection clipboard" which you paste via clicking the middle mouse wheel.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christopher Plewright
@kallisti5
I know what you mean about the linux clipboard, and text goes into the clipboard on selection. I like that when I am on linux.
At the moment, my clipboard is integrated with the MS-windows clipboard, so it may be just lucky that it works for me that way.
I'm opening up a separate linux desktop session to try out what happens when windows clipboard is not in the middle.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christopher Plewright
OK, yes, I see now. E353
I had to disable the windows clipboard sharing in my Xrdp connection.
Thanks for showing me.
I wondered if I was missing something, you know when something seems too easy... it probably is...
So, now, I'm gonna play around with that for a while. Not giving up yet. lol.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yegappan Lakshmanan
I wonder if it is related to how your system clipboard is configured in your session.
Default configuration.
Also, is your vim running on the same system, or you ssh or tmux or somewhere in there?
Same system, or other system via ssh. Same behaviour
- Done
- Done
- Done
4.a Highlight clipboard. Highlight text. p to paste in vim. E353: Nothing in register ''
4.b I copy text in Opera (by actually clicking copy). Highlight and do a full copy.. press p in vim E353: Nothing in register ''- I never do this. Just yy, y1l, y1w, etc.
- etc
As I mentioned, using the selection clipboard. You don't have to copy and paste in Linux, just highlighting text puts it into your "selection clipboard" which you paste via clicking the middle mouse wheel.
vim-dev ML
wrote:
> I wonder if it is related to how your system clipboard is configured in
> your session.
>
> Default configuration.
>
> Also, is your vim running on the same system, or you ssh or tmux or
> somewhere in there?
>
> Same system, or other system via ssh. Same behaviour
>
> 2. Done
> 3. Done
> 4.a Highlight clipboard. Highlight text. p to paste in vim. E353:
> Nothing in register ''
> 4.b I copy text in Opera (by actually clicking copy). Highlight and do
> a full copy.. press p in vim E353: Nothing in register ''
> 5. etc
>
> As I mentioned, using the selection clipboard. You don't have to copy and
> paste in Linux, just highlighting text puts it into your "selection
> clipboard" which you paste via clicking the middle mouse wheel.
>
When selecting the text using the mouse, can you try pressing the Shift key?
- Yegappan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Alex von Gluck IV
When selecting the text using the mouse, can you try pressing the Shift key?
No difference.
Is anyone working on vim mouse mode and making it the default actually using Linux as a desktop? 😆
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Samuel Sloniker
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christopher Plewright
I think it depends on the terminal
Testing in an xfce4 desktop session...
Shift does make it work for me in gnome-terminal, kitty, xterm. And, I checked it works regardless of settings mouse 'a' or none.
In xfce4-terminal, the middle click just works in vim to put the selected text from opera. And it works regardless of the mouse setting 'a' or none. This was a nice surprise :) Shift was not needed, but it also worked anyway.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Balki
Why not have a popup context menu on right-click with option to disable mouse and/or a message Hold <Shift> to pass mouse events to terminal
neovim shows below pop-up menu. I prefer to just have an option to disable mouse than go to help.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Dominique Pellé
@zewpo wrote:
Shift does make it work for me in gnome-terminal, kitty, xterm. And, I checked it works regardless of settings mouse 'a' or none.
Shift has always worked for me in any terminal I tried (xfce4-terminal, gnome-terminal, xterm, alacritty...) on Linux or macOS. It also works in tmux and when running Vim inside a Vim terminal.
You have to hold Shift as you click or select text in the terminal. Maybe you're doing it differently?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christopher Plewright
[Shift does make it work] ⊆ [Shift has always worked ]
then [you're doing it differently] is false
maybe you meant to ask @kallisti5 if he is doing it differently?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Alex von Gluck IV
Shift makes no difference for me. Can you provide documentation on what shift is supposed to do?
I can reference the FreeDesktop clipboard specification which doesn't mention anything about required modifiers:
https://specifications.freedesktop.org/clipboards-spec/clipboards-0.1.txt
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
> Shift makes no difference for me. Can you provide documentation on
> what shift is supposed to do?
itself, handling the selection and usually also paste. Without shift
the events go to the application (if the applicatin has enabled this).
> I can reference the FreeDesktop clipboard specification which doesn't
> mention anything about required modifiers:
>
> https://specifications.freedesktop.org/clipboards-spec/clipboards-0.1.txt
interaction between the application (including a terminal) and the X
server.
--
GALAHAD turns back. We see from his POV the lovely ZOOT standing by him
smiling enchantingly and a number of equally delectable GIRLIES draped
around in the seductively poulticed room. They look at him smilingly and
wave.
François Ingelrest
Shift makes no difference for me. Can you provide documentation on what shift is supposed to do?
I can reference the FreeDesktop clipboard specification which doesn't mention anything about required modifiers:
https://specifications.freedesktop.org/clipboards-spec/clipboards-0.1.txt
vim-dev ML
On Tue, 13 Dec 2022 at 02:31, Alex von Gluck IV ***@***.***>
wrote:
> Shift makes no difference for me. Can you provide documentation on what
> shift is supposed to do?
>
> I can reference the FreeDesktop clipboard specification which doesn't
> mention anything about required modifiers:
>
> https://specifications.freedesktop.org/clipboards-spec/clipboards-0.1.txt
>
Can't you automatically alias vim to vim -c 'set mouse=' when you ssh into
a machine ?
Something like this :
ssh -t MY_MACHINE 'bash --init-file <(echo "alias vim=\"vim -c \\\"set
mouse=\\\"\"")'
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
xandro0777
If it did anything on my Debian system (xterm) it was totally non-obvius.. would anyone enlighten me what it was actually supposed to do?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Alex von Gluck IV
Ok... I finally figured out the behavior.
-
Middle click in vim without holding shift pastes the VIM clipboard buffer
-
Middle click while hosting shift in VIM pastes the "PRIMARY" from the OS or the "CLIPBAORD" buffer from the OS. (it seems to be whichever was populated last?)
Essentially, vim is mixing up the clipboards in a weird way which directly is against the freedesktop clipboard specification above.
As such, I recommend vim disabling mouse mode everywhere, or reversing the weird non-standard logic.
(Holding shift plates the vim clipboard instead of pasting the OS clipboard)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
Alex von Gluck wrote:
> Ok... I finally figured out the behavior.
>
Vim does not have a clipboard buffer. You probably mean the star
register.
> * Middle click while hosting shift in VIM pastes the "PRIMARY" from
> the OS *or* the "CLIPBAORD" buffer from the OS. (it seems to be
> whichever was populated last?)
What do you mean with "hosting shift"?
What happens here is done by the terminal. Vim has no influence on it.
There are various preferences here and the X server especially has a lot
of options. Most terminals have configuration options for this.
> Essentially, vim is mixing up the clipboards in a weird way which
> directly is against the freedesktop clipboard specification above.
written by a small group of people and not widely supported. It's much
better to talk about what users want than some random standard that was
found on the internet. The way Vim uses the X
selection/cut-buffer/clipboard was tuned over many years and it is very
unlikely to change, because that would upset very many users.
> As such, I recommend vim disabling mouse mode everywhere, or reversing
> the weird non-standard logic.
> (Holding shift plates the vim clipboard instead of pasting the OS clipboard)
recommendation.
--
You cannot propel yourself forward by patting yourself on the back.
Bram Moolenaar
> I read in some comments above that "people" expect the mouse to "just
> work". I did absolutely not notice that it would "work" in any way -
> other than breaking cut&paste.
text? Or resize a window with the mouse?
> If it did anything on my Debian system (xterm) it was totally
> non-obvius.. would anyone enlighten me what it was actually supposed
> to do?
--
"Intelligence has much less practical application than you'd think."
-- Scott Adams, Dilbert.
Alex von Gluck IV
For any future lurkers, this sums up why mouse mode is default now:
brammool commented [on Jun 11, 2018]
Most terminal programs use only line editing. Vim is a full screen editor, where using the mouse is expected to work. I get quite annoyed when I run into a setup where it doesn't work.
I really don't see how users can use Visual mode, resize windows and many other things without the mouse.
tldr; the vim dictator doesn't understand how to use visual block mode without a mouse.
Don't expect any movement here. I give up.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.