I'm running a Ubuntu virtual machine on a Win10 host (via vagrant) and having trouble getting tmux to behave properly when running vim in one of its panes. On its own, vim displays fine; however, when inside a tmux pane, the line breaks get all confused and it tears across the pane boundaries:
I'm using ConEmu in the video; however, the same thing happens in cmd.exe.
Update: changing panes fixes the issue temporarily, but certain kinds of edits make it happen again.
You can, once vim is running, set the width (the number of columns) :
according to vim's help: the "columns" or "co" setting is:
'columns' 'co' number (default 80 or terminal width)
global
{not in Vi}
Number of columns of the screen. Normally this is set by the terminal
initialization and does not have to be set by hand. Also see
|posix-screen-size|.
When Vim is running in the GUI or in a resizable window, setting this
option will cause the window size to be changed. When you only want
to use the size for the GUI, put the command in your |gvimrc| file.
When you set this option and Vim is unable to change the physical
number of columns of the display, the display may be messed up. For
the GUI it is always possible and Vim limits the number of columns to
what fits on the screen. You can use this command to get the widest
window possible:
:set columns=9999
Minimum value is 12, maximum value is 10000.
You should also check if you don't have "COLUMNS" set in your environment (and therefore "inherited" inside tmux), and in that case vim may be relying on its value instead of interrogating the terminal? (here is an exemple of discussion around that kind of issue, but for another environment (debian linux, instead of windows tmux for you) : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605279 : shows that you shouldn't export COLUMNS before launching tmux, if possible)
You should also be able to launch vim while specifying the COLUMNS value just for the duration of its invocation, with:
COLUMNS=40 vim
for example
Related
When using gVim, whenever I switch between two tabs where one tab is split vertically and the other is not, the horizontal size of the window is decreased by a small amount (probably one column).
This is really annoying as it forces me to resize the window every few minutes.
The behaviour can be reproduced as follows:
start gvim
create new tab :tabnew
split window vertically Ctrl+W v
switch tags gt (--> window size will decrease)
Is this somehow intended behaviour or is it just a bug? Anyway, is there some way to prevent this?
In case it matters: I am using Ubuntu 12.04 with Xfce, using the vim version from the repos (7.3, Included patches: 1-429).
Update 1
I followed the instructions of the FAQ posted by nMontu and tracked the issue down to the following line of my .vimrc:
set guifont=Meslo\ LG\ S\ DZ\ 12
Actually the issue is the font size, if I change it to
set guifont=Meslo\ LG\ S\ DZ\ 10
the problem is gone (leaving me with the problem of a too small font, of course...). It's only the font size, changing the font itself does not solve the problem. For other font sizes != 10 the problem is also there (I tested with sizes 8-14).
Update 2
I updated vim to version 7.4 and when testing with empty buffers, the problem is gone, even when using a font size != 10. However, as soon as I open files, it is there again :(
Following your steps on Linux Mint doesn't show the error. I've executed one hundred tabpage switches and the there was no change on the window size (qmgtq to record a macro, 100#m to execute it).
Notice that vim 7.3 is quite old, you should try updating it to 7.4. But the error you are experiencing probably isn't a vim bug. You should try to follow follow the procedure described on Vim-FAQ 2.5:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual
runtime files or any plugin that is distributed with Vim or whether it
is a simple side effect of any configuration option from your .vimrc
or .gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
this starts Vim in nocompatible mode (-N), without reading your
viminfo file (-i NONE), without reading any configuration file (-u
NONE for not reading .vimrc file and -U NONE for not reading a .gvimrc
file) or even plugin.
If the error does not occur when starting Vim this way, then the
problem is either related to some plugin of yours or some setting in
one of your local setup files. You need to find out, what triggers the
error, you try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load
any plugins. If the error occurs this time, the error is possibly
caused by some configuration option inside your .vimrc file. Depending
on the length of your vimrc file, it can be quite hard to trace the
origin within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half
of your .vimrc. If it doesn't happen, the problematic setting must be
in the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and
move your way along, until you find the problematic option. If your
.vimrc is 350 lines long, you need at a maximum 9 tries to find the
offending line (in practise, this can often be further reduced, since
often lines depend on each other).
If the problem does not occur, when only loading your .vimrc file, the
error must be caused by a plugin or another runtime file (indent
autoload or syntax script). Check the output of the :scriptnames
command to see what files have been loaded and for each one try to
disable each one by one and see which one triggers the bug. Often
files that are loaded by vim, have a simple configuration variable to
disable them, but you need to check inside each file separately.
Edit
Vim's documentation is extremely well-written and very comprehensive. You are likely to find most of the details about Vim there. It also has a great FAQ, which can be viewed directly on Vim through this nice plugin.
Vim-FAQ 31.2 has a list of useful references:
For more information, read
'guifont'
'guifontset'
'guifontwide'
font-sizes
-font
-boldfont
-italicfont
-menufont
-menufontset
In special, on :help font-sizes:
Note: All fonts (except for the menu and tooltip) must be of the same
size!!! If you don't do this, text will disappear or mess up the
display. Vim does not check the font sizes. It's the size in screen
pixels that must be the same. Note that some fonts that have the same
point size don't have the same pixel size! Additionally, the
positioning of the fonts must be the same (ascent and descent). You
can check this with "xlsfonts -l {fontname}".
I don't know the font you mentioned (Meslo), but I would guess it is not mono-spaced.
Edit 2
Meslo is mono-spaced
It is possible that Meslo won't work, similar to what is stated in its FAQ:
Q: Can I use Meslo with ... ?
A: As for ... I don't know (yet). You may have to try it out. I do
know however that for the time being there appears to be a problem
with an application called SecureCRT which does not recognise Meslo as
a monospaced font. (see also: issue 2)
And issue 2 seems similar to your problem.
I'm trying to use Meslo in a terminal app that requires a fixed-width
font, but when I choose Meslo, it's claiming the font isn't
fixed-width.
You also mentioned that
and besides I am getting the same issue with other mono-spaced fonts
(i.e. 'Monospace') as well.
It is strange that it occurs with common mono-spaced fonts, as this kind of problem would certainly have been reported. If you are sure that it happens with fonts that follow the requirements on the Vim documentation then you should fill a bug report.
I am using CommandT and when I use <leader>t, the window only starts with a partial set of directories shown, whereas I would prefer to have all of the directories show and/or files. I prefer that it takes up most of the height of vim, in the terminal, as possible. Is there anyway to make a change to CommandT? I have read the help but don't seem to see anything related to why I only see 10 results to start with instead of as many as the window can show. I have not changed any mappings or options for the plugin.
Thank you for your help.
This behavior has been changed by the commit "Switch some defaults to more reasonable values".
Insert
let g:CommandTMaxHeight=0
into your .vimrc file. Just running this command after VIM has already started up did not work for me presumably because the Command-T ruby code makes a copy of this value when it starts up.
g:CommandTMaxHeight is defined as:
The maximum height in lines the match window is allowed to expand to.
If set to 0, the window will occupy as much of the available space as
needed to show matching entries. (default: 15)
Run the VIM command
:help g:CommandTMaxHeight
for more details
I am testing the various different terminals that I tend to use to SSH into Linux boxes that I have Tmux set up on.
Basically I noticed this behavior, and I am hoping that somebody could offer an explanation of what's going on. Now it may be the case that this is specific behavior that affects the Prompt app.
I am using Vim within Tmux, and on Panic's Prompt app on my iPhone5 I was having the behavior that 256 colors were not enabling when the .vimrc set the colors using the set t_Co=256 directive. Here, Vim was correctly displaying the colors when it was not run through Tmux. Also, OS X's Terminal.app correctly rendered the colors (I did not test PuTTY with this on windows unfortunately) with Vim in Tmux.
Then I swapped out set t_Co=256 for set term=xterm-256color and now the colors work when using Vim through Tmux.
Note also that I tested both set -g default-terminal "xterm-256color" and set -g default-terminal "screen-256color" settings for Tmux and this change had no effect on behavior.
When you don't use tmux or screen, you only need to configure your terminal emulators to advertise themselves as "capable of displaying 256 colors" by setting their TERM to xterm-256color or any comparable value that works with your terminals and platforms. How you do it will depend on the terminal emulator and is outside of the scope of your question and this answer.
You don't need to do anything in Vim as it's perfectly capable to do the right thing by itself.
When you use tmux or screen, those programs set their own default value for $TERM, usually screen, and Vim does what it has to do with the info it is given.
If you want a more uniform (and colorful) behavior, you must configure them to use a "better" value for $TERM:
tmux
Add this line to ~/.tmux.conf:
set -g default-terminal "screen-256color"
screen
Add this line to ~/.screenrc:
term "screen-256color"
Now, both multiplexers will tell Vim they support 256 colors and Vim will do what you expect it to do.
edit
My answer assumes that you are able to edit those configuration files but, since you are able to edit your ~/.vimrc, I don't think that I'm that far off the mark.
edit 2
The value of the term option (retrieved with &term) is the name of the terminal as picked up by Vim upon startup. That name is what you are supposed to setup in your terminal emulator itself.
The value of the t_Co option (&t_Co) is what Vim considers to be the maximum number of colors that can be displayed by the host terminal. It is defined according to the entry corresponding to $TERM in terminfo:
term | t_Co
-----------------+------
xterm | 8
xterm-256color | 256
screen | 8
screen-256color | 256
When Vim starts up, it gets the value of the TERM environment variable, queries the terminfo database with that value and stores a number of informations on its environment in several t_… variables among which… the number of colors available in t_Co. Given a "legal" terminal type (one that Vim can lookup), Vim always assumes the correct number of colors.
Setting t_Co to 256 while leaving term to its Vim-defined value — or, more generally, setting t_Co and/or term to values that don't match with the host terminal — makes no sense and will likely create troubles when Vim sends a signal that is not understood by the terminal or vice-versa.
While it is entirely possible to do so, messing with t_Co and term in Vim is both totally useless and possibly harmful.
Again, just setup your terminal emulators and terminal multiplexers correctly. That's really all you need.
If you end up in a terminal multiplexer or a terminal emulator where you can't define a correct TERM, then and only then you can force Vim to assume 256 colors. To that end, changing the value of t_Co is the only thing that makes sense:
if &term == "screen"
set t_Co=256
endif
So… if you can configure each individual part:
terminal emulator: xterm-256color
tmux/screen: screen-256color
vim: nothing
and you are done.
If you can't control every part, use a simple conditional in your ~/.vimrc to set t_Co according to &term but don't change the value of term.
But if you can edit a ~/.vimrc there's no reason you can't edit a ~/.screenrc or ~/.tmux.conf or ~/.bashrc or whatever.
You can use both set t_Co=256 and set term=xterm-256color together.
term tells Vim what terminal type to use, which controls the display/rendering of all aspects of Vim, including how to map key input, redraw the screen, move the cursor, display colors, etc. Normally, Vim can figure this out on its own via the TERM environment variable provided by your OS.
It's often helpful to set it explicitly in case the OS value is incorrect. This is especially true if you're connecting over a network from a terminal emulator that doesn't provide the correct value.
t_Co is one of many terminal options (used by the termcap system that Vim uses for terminal control). It specifically refers to the number of colors the terminal supports. Sometimes you need to override this if the terminal emulation is mostly correct, but Vim isn't correctly identifying the number of colors supported.
I use both of these options in my .vimrc to ensure that Vim uses 256 colors in tmux using all the terminals I like (Ubuntu's gnome-terminal, OSX's iTerm2, and Windows's KiTTY). I also have most of those terminals explicitly configured to send xterm-256color as their terminal type.
My work setup has several terminals open, at different heights (e.g. number of lines). How do I make Vim obtain that number of lines so that it can set itself accordingly with set lines?
I'm on bash with iTerm2.
Update: If my .vimrc doesn't have a set lines statement, Vim should adjust itself by default.
Vim's default behaviour is to take up all of the available height. Or 24 lines if it can't get the information from the Terminal emulator according to :h lines.
set lines=52 works in MacVim/GVim but it's not really supposed to do anything useful in CLI Vim besides, eventually, changing the terminal's window height.
From my limited use of iTerm2 Vim behaves as it should. So do you want Vim to take less vertical space than what is available? Or more?
Though the reason didn't require it, in case someone comes across this while trying to figure out how to get the number of rows in a terminal at startup... the answer is to use "&lines".
Eg. to enforce laststatus to display unless you are working in a small window.
if &lines > 10 | set laststatus=2 | endif
I have a problem with a setting in my gvimrc. I like to always have all windows the same size so I specify the following:
set lines=90
set columns=90
This works fine except when I open gvim with the -p argument for multiple tabs. The statusline and ruler are hidden until I manually resize the window. This only happens when the lines/columns are specified AND I use the -p argument. Is there a way to prevent this on startup other than manually dragging the window around to redraw the ruler/statusline?
I'm using gvim 7.3.154 in ubuntu 11.10.
The solution to this is actually spelled out when reading the gvim documentation on 'lines', see :help lines.
from :help lines
"If you get less lines than expected, check the 'guiheadroom' option.
When you set this option and Vim is unable to change the physical
number of lines of the display, the display may be messed up."
I was able to set guiheadroom=100 on my system and avoid this problem completely. The 100 was just a guess on my part. The default value for this is 50, so if you run into this problem you should set it to something > 50. I was able to go as small as 80, but your mileage will most likely vary depending on your OS, window manager, etc.