SETUP
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 31 2015 23:35:48)
Included patches: 1-488, 576
Modified by pkg-vim-maintainers#lists.alioth.debian.org
set wildmode?
wildmode=list:longest,full
some plugins: i.e. UltiSnips
Problem
when typing a :call command, where I'd like to invoke some routine of a plugin directely, cmdline completion (with TAB key, by default) stops after the #.
i.e.: I want to complete :call UltiSnips#ListSnippets()
where many other UltiSnips routines are available.
When typing :call ult and press TAB, I get:
:call UltiSnips# with a listing of all possible matches.
When I press TAB further, it toggles through all matches correctely
BUT if I try to contiue typing the function name like :call UltiSnips#List and hit TAB, it wont complete the funtion's name, but ANY completion, that is starting with List (what I typed after the #; ListTemplateSuffixes( in my case)
This has been fixed by recent Vim patch 7.4.516: issue 253: completing function name with a # does not work.
So, you just need to update your Vim (by compiling it yourself; or just wait until your distribution provides such upgrade).
Related
I am trying to reproduce the example in chapter 15 of Steve Losh's "Learn Vimscript the Hard Way" (http://learnvimscriptthehardway.stevelosh.com/chapters/15.html), in the section called "Changing the Start."
First, I start vim with the following command:
vim -u NONE foo
to ensure that no plugins are loaded.
Next I type
print foo(bar)
in the buffer and then enter
:onoremap in( :<c-u>normal! f(vi(<cr>
Finally, I place the cursor over the "p" in "print" and enter cin(. The status line displays:
:<c-u>normal! f(vi(<cr>
with a blinking cursor at the end. I hit enter and the status line then displays:
E488: Trailing characters
The expected outcome, according to the book, is that vim will delete the contents of the parentheses and place you in insert mode between them.
Here is the version info:
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled May 2 2017 03:55:34)
MacOS X (unix) version
Included patches: 1-596
Compiled by Homebrew
TL;DR: use vim -u DEFAULTS foo instead.
That should keep Vim in 'nocompatible' mode, which is needed for <Key> codes to be recognized in mappings.
The symptoms you describe are consistent to having < included in 'cpoptions', which is documented to:
Disable the recognition of special key codes in <> form in mappings, abbreviations, and the "to" part of menu commands. For example, the command :map X <Tab> results in X being mapped to "<Tab>" (5 characters) when < is included; but "^I" (^I is a real <Tab>) when < is excluded.
That is consistent with you getting the literal result of your mapping in your command-line, without proper expansion of the <c-u> and <cr> key codes.
The defaults for 'cpoptions' are:
Vim default: "aABceFs",
Vi default: all flags
So this means < (along with all other flags) will be included by default in Vi mode, which is triggered when 'compatible' is set (or, perhaps more accurately, when 'nocompatible' is not set.)
It turns out that when you use -u NONE in your command-line starting Vim, it will start in 'compatible' mode.
You can use instead -u DEFAULTS, which is quite similar to -u NONE, but it will still load the defaults.vim script shipped with Vim runtime, which will among other things set 'nocompatible'.
From the docs:
When -u DEFAULTS (all uppercase) is passed, this has the same effect as -u NONE, but the defaults.vim script is loaded, which will also set 'nocompatible'.
Using the -u argument with another argument than DEFAULTS has the side effect that the 'compatible' option will be on by default. This can have unexpected effects.
I'm using vim in the terminal a log and I'm getting frustrated with its slow performance. I'm on Debian Jessie using Gnome.
If I open a file in vim do a block select and I to insert on multiple lines there is always a delay from when I press esc to when the change is inserted.
If I do the the same thing in gvim the change is imidiate.
I have tried adding
set ttyfast
set lazyredraw
In my ~/.vimrc but that does not make any noticeable difference.
$ vim --verion
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 20 2015 15:31:14)
Included patches: 1-930
This is completely normal.
In Vim, some special keys (like the cursor keys) are implemented as <Esc> followed by some other character. Therefore, Vim waits a bit after your press <Esc> to determine if you actually wanted <Esc> or if you wanted something else like <Esc>A (<Up>).
See :help 'timeout', :help 'timeoutlen', :help 'ttimeout', and :help 'ttimeoutlen'.
I have install YCM in Vim and <c-x><c-f> for file completion works well. Also I get proper completions for code.
But just noticed that trying to access dictionary seems to fails, when using: <c-x><c-d>. I just get the following displayed:
-- Definition completion (^D^N^P) Pattern not found
Vim version:
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Apr 21 2014 14:54:22)
MacOS X (unix) version
Any ideas?
<C-x><C-d> is "definition completion". It works if the language you work with has an "include" mechanism and Vim is set up to follow includes and to recognize "definitions" for that language.
See:
:help i_ctrl-x_ctrl-d
:help 'include'
:help 'definition'
Dictionary completion is <C-x><C-k> and requires the 'dictionary' option to point to at least one dictionary:
set dictionary=/path/to/dict
See:
:help i_ctrl-x_ctrl-k
:help 'dictionary'
I have installed cvim and NodeTree plugins and generated an exuberant ctags file for my build tree.
This is what my ~/.vim/.vimrc file looks like:
:noremap :TlistToggle
:let Tlist_Show_One_File = 1
:let Tlist_Exit_OnlyWindow = 1
:let Tlist_Use_Right_Window = 1
set tags=./tags;/
set number
set tabstop=4
set incsearch
When I start editing a file, I notice that Ctrl ] does not work and I have to resort to typing ta: funcname - which gets tiring after a while. Interestingly enough, Ctrl T pops me off the tag stack as expected - I don't understand whats going on - how do I fix this?
Incidentally, vim (appears to) completely ignores the contents of my .vimrc file and I always have to type the same commands in the editor, so as to get the settings I want - very annoying.
Last but not the least, I used to be able to type :make in the editor window, drop to the console and then have the build results displayed in a little window which I can then go to and select a line (with an error or warning say), and then have the editor automagically take me to the offending line - unfortunately, I don't remember the plugin (or commands) I used to allow me to build from within vim.
So, how do I:
Fix my vim setup so that I can move to definitions/declarations using Ctrl-]
Fix my .vimrc file so that contents are actually applied to my vim session.
Find the appropriate plugin to install to allow builds (using make) from within vim
You're asking about a weird mix of problems.
Fix my vim setup so that I can move to definitions/declarations using Ctrl-]
The tags functionality is working; I suspect that you have a mapping blocking Ctrl-]. Try
:verbose nmap <C-]>
and
:nunmap <C-]>
Fix my .vimrc file so that contents are actually applied to my vim session.
:echo $MYVIMRC
will tell you the location of the .vimrc that Vim uses. Also, check the output of :scriptnames which scripts get loaded, and read :help vimrc to understand the logic Vim applies.
Find the appropriate plugin to install to allow builds (using make) from within vim
That's built into Vim. With the appropriate 'makeprg' set (it defaults to make), you can run :make. Vim parses the output (through the 'errorformat' option), and you can open the quickfix list via :copen.
Your vimrc is:
~/.vim/.vimrc
If you run Vim 7.4, it should be:
~/.vim/vimrc
or
~/.vimrc
If you run Vim 7.3 or older, it should be:
~/.vimrc
And... what Ingo said.
Whenever I work with multiple buffers, there is always one empty. I would like to not have that if I open a file with vim from the command line (i.e. I don't want to create a new file, or choose to create a new file by naming it first and starting vim with that name). How can I do this?
Edit:
I'm launching gvim the following way:
I have an alias in my bashrc: alias g="gvim --remote-silent"
I open files from the command line with: g name-of-file
At this point (if I didn't already have an instance of gvim open), I have two buffers:
Edit2:
Platform is Linux Mint, version is: VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Mar 24 2011 07:07:39).
I updated my NERDTree plugin as David suggested, but it didn't help. Other plugins I use: Pathogen, a, doxygentoolkit, nerdtree, snipmate, vim-rails,
ack_plugin, easymotion, protobuf, sparkup, yankring,
bufexplorer, matchit, rainbow, surround,
clang_complete, nerdcommenter, repeat
I don't have your problem on
linux, gvim - Vi IMproved 7.3 (2010 Aug 15, compiled Mar 24 2011 07:07:34) Included patches: 1-35
windows gvim - Vi IMproved 7.2 (2008 Aug 9, compiled Aug 9 2008 18:46:22) MS-Windows 32-bit GUI version with OLE support
You are probably looking at a bug.
You might be able to debug things by cleaning your $MYVIMRC (temporarily) and running gvim --noplugin.
Alternatively inspect all settings (like bufhidden and other suspect parties)
:set
:setglobal
and see from which script/plugin they are being set (bufhidden as an example only here):
:verbose set bufhidden
:verbose setglobal bufhidden
You might also inspect autocommands (that might prevent buffers from being wiped)
:verbose au
To avoid this I changed my alias:
g() { [ -z "$(command gvim --serverlist)" ] && command gvim "$#" || command gvim --remote-silent "$#" ; }
If the list of server is empty: launch plain gvim, otherwise launch with remote-silent option.