I am struggling with this odd behavior. I am learning vim and I guess I deconfigure it trying to playing with multiple windows.
Now when I split horizontally a window (using ctrl+ws) and try to move between them, I can only see a window at the same time (I guess the size of the focused window is set to 100% automatically) so I can re-size it again using ctrl+w=, but it's frustating do it many times.
UPDATE:
I am using the spf13 config. And using this my local config in .vimrc.local
Thank you guys :)
You probably have :set winheight=999, this creates this effect.
Find out where it got set via
:verbose set winheight?
and remove that setting, or undo it via :set winheight&.
Related
I have several cpp source files in tabs in vim. I would like to have another tab with command prompt in order to run make. I open net tab , run sh and now I have console. But how to move from this console to other tabs? If I press ctrl+page up I have garbage in console and no tab change. How to move to another text tab when staying in console tab?
As I said, vim 8 or neovim both have an terminal emulator in it.
Since you are using vim 7 here are some other ways:
Tmux as #wizzup mentioned is perfect for this use-case. I think it is the most used Terminal-Multiplexer and extremly mighty. It is complex in comparison but since you are using vim, a steep learning curve should not be a killer point. However there are a few cavehats but you will find thousands of articles to solve them.
GNU Screen is an alternative to tmux, I have no experience with it, but should be usable pretty good with vim too.
With them you can use something like this Plugin which allows you to use the terminal in vim itself. However I haven't tested it but it seems to be rather groomed.
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 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.
Something extremely weird is happening when I open files in vim, and I can't remember doing anything that would have caused it.
Weird behaviors include:
no text being visible until I highlight it in visual mode, at which point it is visible from thereon. ":redraw!" does not make anything visible.
line 1 missing
occasionally the cursor appears one line below where it is editing
statuses become permanent and scroll up from the bottom, rather than just redrawing at the bottom
the vim text not extending to the bottom of the vertically maximized window
I lack the reputation to post screenshots but I'll happily provide any other information that could help in a diagnosis.
ETA: Ah! My .vimrc specified a column/row size. I've removed that line, and so far things are behaving well. Thank you!
vim is terminal based, and errors like this happen when the terminal you are using does not match the terminal vim thinks you are using. Most people use vim with terminal emulators. This kind of thing can happen when you resize the emulator window and vim does not find out about it, or more rarely, when the terminal-identifying-string specified in the environment does not match the terminal emulator you are running.
Without more details about the platform on which you are running vim, it is hard to be more specific-- but as a tip: don't resize the emulator window after it is created but before running vim.
Terminal emulators are supposed to communicate size changes back to the program running within them, but this is not 100% foolproof, especially when you are logged in to a remote machine within the emulator.
If you're doing this from a UNIX (Linux et al), try running :!resize to force your terminal to re-adjust its size parameters. At the very least it'll tell you what the system thinks your window is sized to, which may not match its actual size.
I had a similar problem when using vim with bash. When I switched from bash to zsh, it gave redraw errors where, while I typed, the cursor or screen would appear to go down one row for every 10 characters I typed. Scrolling with arrow keys also caused major display problems along the same lines, but worse.
I had this line in my previous .vimrc, I believe it was to set the color for vim
set t_256
I changed it to set term=xterm=256color and the problem went away.
I'm attempting to edit files on a remote system. I've ssh'd to the system and I start editing with vim.
However, I notice that all the lines are drawing 2 lines above where they really exist in the file. I assumed this was a problem I could fix by dropping my terminal settings to something simpler, but that didn't help.
My TERM variable was set to xterm-color. I set it to vt100, but that didn't fix the line drawing issue. I also noticed that this seems to be specific to vim. emacs doesn't show the problem, and I haven't noticed any odd drawing artifacts in less, more or other paging tools.
Other specifics: I'm ssh-ing into the remote system from a Mac, using the Terminal.app. The remote system is running Ubuntu 9.04.
I'm hoping there is something I just need to set in vim to get it to play nice. If it allows me to keep syntax color highlighting, so much the better.
Zhaojun's suggestion works. Setting TERM=xterm is clearing things up.