It's been like this forever really. Because I worked both on Ubuntu and Mac OS X interchangeably I didn't care as much. Now I think maybe it's time to finally find out what is wrong with it.
THE PROBLEM: When I switch tabs or navigate the lines with arrows or J, K keys and when I do it repeatedly (as if when trying to find the right tab holding Ctrl and hitting Tab) it seems to be delaying the action. When I stop hitting the keys gVim may still be finishing the operations (for instance, I stop hitting Ctrl+Tab, gVim may switch 5 more tabs - the number depends on how long I've been hitting Ctrl+Tab - before it stops).
MacVim with similar settings in .vimrc works just fine. The delays are present both when Compiz is turned off and turned on. Any ideas?
I have experienced similar sluggishness when working with large files. I've found that folded blocks makes it worse, so try and open all folds - zR.
This is a know bug in Ubuntu. Until it is patched in the official repositories, you can use this PPA repository, which contains a fixed version of Vim. I just tried it and it fixes the issue.
Related
I have an instance of vi on a remote server that is not behaving like it used to, and I'm not sure what made this happen.
On my local shell, (and the remote server before this started happening), if I scroll with my mouse/touchpad, it would navigate the cursor within vim. I have checked my .vimrc and there's nothing in it relating to the mouse, and I did not make any changes to it before this issue started.
The only thing I can think of is that a few weeks ago, I was trying to figure out how I could split two files in the same vi instance so I could yank from one file to another, and I tried some : commands that I didn't really understand (didn't get any productive results). And also, I ran tmux once, but I don't think there are any . files that are applying unwanted settings (not sure).
I can't find anything to check the vi settings being applied, but I know that my .vimrc is working, and it's not anything in there (if I comment everything out it still behaves this way).
I just want my vi to respond the same way.
Describing the problem more exactly:
If I scroll, the cursor doesn't move, instead it scrolls on the terminal window, and it shows the previous bash commands instead of scrolling the file being edited. If I navigate using vim keys, it still works.
Randomly, I discovered that it actually had to do with the a specific terminal instance that was causing the issue. Closed it, opened a new one, no issue now. If anyone has any insight on why this could've been, I'd love to know.
.vimrc applies to vim not vi, doesn't it ?
the problem of scrolling might come from your terminal emulator as well.
I usually use embedded terminal in VS code which is not ideal (since it's not made for administration ...) but it's practical with keybinds to jump from one window to another, copy paste ...
I know some colleagues who use, mobaXterm or mremoteNG on windows.
I know I should give a go to Terminator, but it's on linux only and I don't want to run a local vm just for that.
I'm having a bit of an odd problem... recently I've been having some odd situations arising whilst using CoqIDE, namely:
I can't type the letter "v" without holding down the windows/super key.
Pressing backspace moves the focus to the previous tab if multiple windows are open, I can't delete things with it. CTRL+backspace works for deleting chunks though.
The first of the two (may have) happened after I changed my keymap from US to GB but switching back and forth hasn't solved the problem.
Running ARCH linux, everything is up to date and no other applications are affected, I don't have sticky keys on.
Thanks for any suggestions!
EDIT: Tried a reinstall, didn't help...
Solved Edit: Yep, you're completely right I seem to have done some super-fast rebind without noticing. I also learnt that package manager will essentially never touch .config files as they're generated by the app and so aren't under the manager's jurisdiction. Solved!
CoqIDE key bindings and other preferences are stored in .coq/ or .config/coq. They are not deleted on uninstall and are shared if you have various versions of Coq installed at the same time (and this may be a problem).
If you are not worried about losing any specific preferences that you configured, I would advise to just delete this directory and let CoqIDE create it fresh again.
If you are worried, then just have a look at the files (quite long but also quite readable). For instance:
cat .config/coq/coqide.keys | grep "tab"
yields the following on my machine:
; (gtk_accel_path "<Actions>/View/Previous tab" "<Alt>Left")
; (gtk_accel_path "<Actions>/View/Next tab" "<Alt>Right")
PS: your problem might have arisen because key bindings are so easy to redefine in CoqIDE that you can do it without noticing: just open a menu (example: View), hover some option (for instance: Previous tab), type something on the keyboard (for instance v) and voilà v is now a shortcut for Previous tab.
I am aware that the mousefocus option is only supposed to work in gVim. But I was wondering, if it's possible to have the console Vim switch to different windows in response to mouse clicks, would it be not possible to easily add following mouse movement to it, too?
I'm an xmonad user, I love the focus following the pointer feature, I do a lot of pdf viewing and browsing while writing in Vim, and I'd be so much happier if I didn't have to keep mentally switching back and forth between two different types of focus changing.
If that's completely not possible, I guess opening new Vim windows (as with :split) in new instances of the terminal is no easier to do?
It would not be at all simple to add this. Using the mouse within the terminal works by vim sending control codes to the terminal requesting that mouse actions be sent as part of the input stream. Terminals only report clicks not changes in the pointer position, so vim has no way of knowing where the mouse is.
With major changes it would likely be possible for a vim with X support to get pointer activity directly from the X server, but that would likely be reported by pixel rather than by character so further work would need to be done before it could determine which vim window is currently under the pointer.
set mouse=a
should do the trick but it will probably depend on your terminal emulator. See :help 'mouse'.
This works for Windows 7/Cygwin 32bit mintty/vim 7.3: (I DO NOT use gvim!)
Having installed this: http://ehiti.de/katmouse/, I can scroll the window under my cursor without having to have clicked to select a window, click-selecting of single vim-windows works, too. It does not pull the vim window to the foreground, if another window overlaps it, if that is what you desire. Still it can be scrolled without click-selecting it first.
So:
Check if there exists a software paket for your distribution, that implements your desired mouse behavior on the OS level. When this works for my self-compiled vim in cygwin, it might very well work with console vim on linux, too.
This post here serves as evidence, that it is possible at all, that is the reason this was not made a comment. When I am on linux again I will investigate this further and update this post, but that might take a while.
On set mouse=a: The vim help states you a need a terminal capable of handling mouse inputs, further information can be found here. :help ttymouse might also be helpful, i.e. if you have a xterm-compliant console, but :help term is set to something else.
UPDATE: (Freshly installed Fedora 19 with packages, no self-compiled stuff.)
Fedora 19 + se mouse=a = scrolling in single console vim window with several buffers opened next to each other independently works, too. Window manager used is LXDE.
I'm trying to use xdebug with vim on linux. I follow the instructions to install xdebug and after that I can see the information about xdebug if I call phpinfo() from a file inside the apache server.
After open a file in vim, it is supposed that when I press F5 it should show something like "waiting for a new connection on port 9000 for 10 seconds...", but it doesn't show anything..
Any idea?
I would recommend you look at a new vim debugger plugin, called vdebug: https://github.com/joonty/vdebug -- it is actively developed and seems very capable.
I had the same sort of problem, it turned out that my terminal emulator was capturing the keypress and not sending it to vim (I think). Remapping the functions to different keys solved the problem.
It could actually be his/her keyboard. If the keyboard has mult-media functions as well as F1-F12 on them... then there is, usually a "F-Lock" key next to the row of function keys that will turn on/off the function key behavior. Really annoying, IMHO, for the new keyboards sold these days.... and rarely does the keyboard have a light to indicate the ulterior operation of said function keys.
I say this cuz, that is exactly what happened to me just now.
I tend to maximize a terminal to one screen, and vertically split several windows in Vim. Everything works fine for the first few windows on the left, but clicking past about the 220th column in the terminal doesn't work correctly. Any mouse clicks past column 220 seem to be wrapping around to column 1. I've tested in xterm, urxvt, and Gnome terminal with and without tmux/screen; always the same behavior. If I greatly increase the size of the font in Gnome terminal, I can click on the last column (although it is no longer past column #220).
If I run a command in a terminal that prints to standard output, I can click all the way to the right of the terminal. The problem does seem to be related to Vim.
I have set mouse=a in .vimrc. I'll post the entire file on request, but it doesn't seem to have anything else related to the mouse.
It's probably irrelevant, but I'm running Xmonad+Gnome. Thanks in advance.
This has been fixed in Vim 7.3.632. See :h sgr-mouse. Or just put this in your ~/.vimrc:
set ttymouse=sgr
If you want to be compatible with versions that don't have mouse_sgr compiled in, use:
if has("mouse_sgr")
set ttymouse=sgr
else
set ttymouse=xterm2
end
To see if your version of Vim has mouse_sgr, run vim --version from the command-line, or in Vim, enter :version, and look for +mouse_sgr.
If you're using older versions of screen, or terminal emulators that don't support SGR, you may need to upgrade or switch. These settings work with all new versions of screen, tmux, gnome-terminal, PuTTY/KiTTY, iTerm2, and Terminal.app, using TERM=xterm-256color or screen-256color.
Update: If you're using neovim, SGR support is enabled by default.
Edit:
I deleted the bug report, as that tracker was for the website, not the text editor.
In looking in the correct place for an existing bug report, I found this:
http://groups.google.com/group/vim_dev/browse_thread/thread/4c137e64d2032441/b3993eaa89589619?lnk=gst&q=mouse#b3993eaa89589619
To summarize, it was an xterm limitation that has been lifted. However, Vim does not yet support columns longer than 223.
Original:
This seems to be a bug, as supported by comments made by redstreet. I filed a bug report:
https://sourceforge.net/tracker/?func=detail&aid=3389331&group_id=27891&atid=391887
A few years later, the bug still seems to be present.
The solution I found is neovim: a modern refactor of vim. Among other features, this bug has been resolved.
I simply copied my .vimrc into .nvimrc, and my plugins just worked with nvim. Maybe I'll just keep using that.