This has been mentioned on the blog in the past, but readers email me about it often enough that it deserves a formal tip. You can use the mouse to resize windows in Vim if you set your mouse as follows.
:set mouse=a
This will even work over a remote ssh session if you also set your term appropriately.
:set term=[the appropriate setting]
Options for term settings are as follows:
in the GUI: "builtin_gui"
on Amiga: "amiga"
on BeOS: "beos-ansi"
on Mac: "mac-ansi"
on MiNT: "vt52"
on MS-DOS: "pcterm"
on OS/2: "os2ansi"
on Unix: "ansi"
on VMS: "ansi"
on Win 32: "win32"
If the mouse setting interferes with your operating system's copy and paste ability such as the select to copy feature under X windows, you can revert to the standard behavior by holding shift while selecting text.
Setting your mouse as described also prevents accidental terminal scrolling with the mouse wheel when editing a file remotely and causes Vim to scroll within the current buffer instead.
Thanks to mmmattos for emailing me and providing the motivation for this tip.
Showing posts with label mouse. Show all posts
Showing posts with label mouse. Show all posts
Friday, September 18, 2009
Thursday, December 11, 2008
Ubuntu: Downgrading X.org
First things first, if you use multiple monitors and you're thinking about upgrading to Ubuntu 8.10 (Intrepid), I would recommend holding off. A good number of users, myself included, have experienced a very annoying bug where the mouse spontaneously loses it's ability to click. The only way to regain mouse support is to kill X with ctrl-alt-backspace (ugh). I've been able to faithfully reproduce the bug by doing the following:
* Enable Xinerama in xorg.conf
* Open firefox fullscreen on both monitors
* Rapidly move the mouse between monitors
It's worth noting that this bug has nothing to do with what window manager you're using. I've experienced it under Gnome, AwesomeWM, and Xmonad. The bad news is that even though a lot of people are complaining about it, the bug has not been fixed. As of right now, the only reliable method to regain workstation stability seems to be downgrading X.org back to the Hardy packages. To assist anyone who might be Google'ing this issue, here are the instructions for doing so.
Log into a text console as root and shut down X with '/etc/init.d/gdm stop'.
Add the following to your /etc/apt/sources.list:
deb http://us.archive.ubuntu.com/ubuntu hardy main
deb http://us.archive.ubuntu.com/ubuntu hardy-updates main
deb http://us.archive.ubuntu.com/ubuntu hardy-security main
Run apt-get update.
Purge all the packages you can by doing the following:
cd /var/lib/dpkg/info/
dpkg --purge `ls *xorg*.list | sed s/.list// `
Some of these will fail to purge due to dependency issues. That's OK. Continue with the instructions.
Reinstall the packages from the Hardy repo:
apt-get --reinstall install x11-common/hardy xorg/hardy xserver-xorg/hardy xserver-xorg-core/hardy xserver-xorg-input-kbd/hardy xserver-xorg-input-mouse/hardy
Note that if you're using a stock Ubuntu video driver such as the Matrox driver you will need to include it in the list as well (xserver-xorg-video-mga/hardy). I use the third-party Nvidia driver, so it wasn't necessary to include it in the list.
After this, you can start X with "/etc/init.d/gdm start" and hopefully login to a working desktop. The final step is to go into synaptic and lock the reinstalled packages to avoid the upgrade manager from nagging.
Thanks to Nelson for providing these instructions, which I've modified slightly for presentation here.
* Enable Xinerama in xorg.conf
* Open firefox fullscreen on both monitors
* Rapidly move the mouse between monitors
It's worth noting that this bug has nothing to do with what window manager you're using. I've experienced it under Gnome, AwesomeWM, and Xmonad. The bad news is that even though a lot of people are complaining about it, the bug has not been fixed. As of right now, the only reliable method to regain workstation stability seems to be downgrading X.org back to the Hardy packages. To assist anyone who might be Google'ing this issue, here are the instructions for doing so.
Log into a text console as root and shut down X with '/etc/init.d/gdm stop'.
Add the following to your /etc/apt/sources.list:
deb http://us.archive.ubuntu.com/ubuntu hardy main
deb http://us.archive.ubuntu.com/ubuntu hardy-updates main
deb http://us.archive.ubuntu.com/ubuntu hardy-security main
Run apt-get update.
Purge all the packages you can by doing the following:
cd /var/lib/dpkg/info/
dpkg --purge `ls *xorg*.list | sed s/.list// `
Some of these will fail to purge due to dependency issues. That's OK. Continue with the instructions.
Reinstall the packages from the Hardy repo:
apt-get --reinstall install x11-common/hardy xorg/hardy xserver-xorg/hardy xserver-xorg-core/hardy xserver-xorg-input-kbd/hardy xserver-xorg-input-mouse/hardy
Note that if you're using a stock Ubuntu video driver such as the Matrox driver you will need to include it in the list as well (xserver-xorg-video-mga/hardy). I use the third-party Nvidia driver, so it wasn't necessary to include it in the list.
After this, you can start X with "/etc/init.d/gdm start" and hopefully login to a working desktop. The final step is to go into synaptic and lock the reinstalled packages to avoid the upgrade manager from nagging.
Thanks to Nelson for providing these instructions, which I've modified slightly for presentation here.
Friday, November 16, 2007
Mouse Support
I usually try to avoid the mouse for reasons of efficiency; however, there are times when the mouse can actually save you time. A good example of which is resizing windows. Vim 7.x has an option to respect the mouse even when you're not using Gvim. To enable mouse support type :set mouse=a.
Subscribe to:
Posts (Atom)