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
Related
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
Here i found a link to this script which saves the screen size and position when exiting vim. If i use :mksession ~/session.vim in fullscreen mode with several splits, exit vim (gvim) and open it like: gvim -S ~/session.vim it messes up the sizes of the splits (pretty randomly. All splits have different sizes). They are all shifted to the left. Is there already a way of doing this properly?
Have you verified your 'sessionoptions'? It should include 'resize' and 'winsize' at the very least to get what you're looking for. :help 'ssop' will give you the list of options to set for what gets saved into session files.
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'm not sure if this is the default behavior, but when I open multiple windows, I get multiple status bars (see below). This is ideal when I have multiple windows open. However, when I try to search, or issue a command, it goes all the way down to the bottom (see below). Is there any way to force it to show in, over or under the status bar of each window?
I think you are confusing status-line and command-line. Type:
:help status-line
and:
:help command-line`
There's no way to move command-line somewhere else, unfortunately, nor combine these two. You can even turn the status line for "last" window (the bottom ones) by using:
:set laststatus=0
just to emphasize the difference.
No, there is no way to show the command line anywhere but at the bottom.
The statuslines can be modified in that way that you can turn them off completely, all of them (the laststatus option modifies this), have them show only when there are at least two windows open (laststatus=1 behaviour, the one you have), or have them show all the time for all windows (laststatus=2).
One last thing ... regardless of where it is, the command line (at the bottom) issues buffer specific commands to the active buffer (the one with the green statusline), so there really isn't a need for let's say, four of them ...
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.