Snipmate used to expand snippets, but it stopped working. I changed a few
unrelated things in my vimrc, but I don't know what caused it (and I have no
backup of the old file).
My investigation so far:
Pressing tab doesn't expand and instead inserts whitespace, check :verbose imap:
i <Tab> * =TriggerSnippet()<CR>
Last set from ~\vimfiles\bundle\snipmate.vim\after\plugin\snipMate.vim
Seems reasonable, I wonder what happens if I type <C-R>=TriggerSnippet()<CR> manually? Same result, whitespace is inserted. Weird.
I edited in a few :echo statements into the TriggerSnippet() source code, apparently the function is not executed at all?
Type def in a Python file, position the cursor on the f or on a space next to it, enter :call TriggerSnippet(). This time the function actually runs (debug echos visible), but no expansion. But maybe it really wants to be called from insert mode, not from ex.
Running the following piece of code I found in this question gave an empty result:
fun! GetSnipsInCurrentScope()
let snips = {}
for scope in [bufnr('%')] + split(&ft, '.') + ['_']
call extend(snips, get(s:snippets, scope, {}), 'keep')
call extend(snips, get(s:multi_snips, scope, {}), 'keep')
endfor
return snips
endf
echo keys(GetSnipsInCurrentScope())
----> []
Weird. Why can I run TriggerSnippets via an ex command but not via <C-R>=? What does it mean that there are no snippets defined? Even more important, how do I fix it?
As for my config, nothing in my vimrc mentions Snipmate, I installed it via pathogen on Vim 7.4 on Win7, it worked before. I'm using the latest git version (installed it yesterday and it worked) of Snipmate and the git tree is clean (except for the few debug statements, but it doesn't work without them either).
Edit: Updated after Conspicuous Compiler's explanation about s: variables.
Edit 2: Plugins I have installed using Pathogen: ctrlp-py-matcher
ctrlp.vim,
jedi-vim,
pytest-vim-compiler,
python-mode,
snipmate.vim,
syntastic,
vim-easymotion,
vim-fugitive,
vim-sensible,
vim-sleuth,
I had a snipmate clone from an ancient repository installed. I still have no idea why it worked and then suddenly stopped.
Pro tip for others: check where you get snipmate from. It needs to be (at the time of writing):
https://github.com/garbas/vim-snipmate
If you're using snipmate.vim, get rid of it and install the correct one. Note that the new vim-snipmate has a few dependencies that you need to install as well (see the github repo).
If you are chaning things already, you might also consider switching directly to ultisnips, which seems to be the modern (2015) replacement for snipmate. It requires a vim with +python support, though.
Related
Today I installed a recent 64-bit Gvim:
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Dec 13 2020 23:02:22)
MS-Windows 64-bit GUI version with OLE support
Included patches: 1-2143
Compiled by appveyor#APPVYR-WIN
...
I used to be a vimmer but switched to emacs and evil-mode a long time ago. I'm investigating whether I should return to vim, so ...
Strangely enough, the Ctrl-] key plays dead man in vim. It does not jump to the tag under the cursor, nothing happens when I hit that key, no reaction at all.
Jumping to a tag with <C-LeftMouse> does work.
The physical key does work. When I ask Emacs about this key, it replies:
C-] runs the command abort-recursive-edit (found in global-map), which
is an interactive built-in function in ‘C source code’.
It is bound to <menu-bar> <minibuf> <quit>, C-], C-}.
(abort-recursive-edit)
Abort the command that requested this recursive edit or minibuffer input.
I've also checked using the key history tool in an autohotkey script: both the Ctrl and the ] are properly traced.
To verify whether I caused the problem in the small .vimrc and .gvimrc scripts that I created in the short time I've been trying vim, I ran both vim and gvim without my initialization files:
vim -u NONE -U NONE
gvim -u NONE -U NONE
Same problem, the key doesn't work.
Yesterday I accidentally installed the latest official 32-bit windows installer (which I removed today and replaced with this 64-bit version). I did hit this problem at the first run of the freshly installed gvim, but postponed looking into it until after my python support problem was duly fixed (thanks filbranden).
So it occurs in both the 32- and 64-bit versions, go figure...
But this is really unfortunate, I don't want to have to grab for the mouse whenever I want to jump to one of the help-tags.
Of course, I would like to understand and fix this. But as long as there's no fix, I'd like to remap the functionality to another key, but I have no idea how to do that.
Any help either to fix the original problem, or in remapping the tag-jumping functionality would be highly appreciated.
Thanks in advance,
Guido
It should be easy enough to remap this particular combination like any other, to permanently set the binding add the following line to your vimrc:
nnoremap <C-]> :command-you-want<CR>
Typically, the command you are looking for is :ta which can be mapped like so:
nnoremap <leader>t :ta<CR>
You should be able to map it to whatever your Left Click is doing as well. If you check in :help index it should show you your current bindings. For me both C-LeftMouse and C-] are doing :ta I suspect your C-] isn't for some reason. You can try setting it to that manually as in the above example.
Personally I have a baked potato for a hippocampus and find I forget more advanced bindings all the time so i keep :help index bound to F1.
I recently installed a plugin called unimpaired by Tim Pope on vim (gVim) installed on Windows. I use pathogen for managing plugins. In case it matters, I have also installed AutoHotKey to swap Esc and Caps Lock by means of a simple script, which AutoHotKey understands. Before installing the mentioned plugin, commands could be typed at a slow speed and vim (gVim) would recognized them. For example, if you typed [p with a slight pause between [ and p, vim would still recognize the command. But now, after installing the plugin, when I use the commands ( for example [b ) mentioned in the documentation (helpfile) of the plugin, the commands are not recognized when they are typed slow with pauses between the keys. However, they work fine, when typed at a quick speed. Also, native commands are still working fine. Is the plugin built that way, or is something wrong elsewhere?
Have a look at the following value:
:verbose set timeoutlen?
That's the time (in milliseconds) that you have between typing each key of a mapping (with a default of 1 second).
If you're only now experiencing these problems, that may be because:
a plugin has decreased the value (the :verbose should tell you)
you only now use plugins that have "longer" mappings; beforehand you just didn't notice
In any case, if you're "suffering" under this, just increase the value in your ~/.vimrc.
I am using vim The-NERD-Commenter plugin along with vundle. But I am not able to get the plugin to work.
I have my leader ley mapped to ,. When I run the :scriptnames command I see that ~\vimfiles\bundle\The-NERD-Commenter\plugin\NERD_commenter.vim is listed in the output. I am also able to bring up help for NERDCommenter using :help NERDCommenter command which tells me that the plugin is installed correctly. But when I try to toggle a comment using <leader>c<space> which translates in my case to ,c it invokes the change command instead.
I have my .vimrc file here https://gist.github.com/bAmrish/be1aac3aeb087925a3e5
Update:
It looks like if I remove the leader key mapping from my .vimrc file then the plugin starts working with the default leader key \.
Please let me know what am I doing wrong.
Thanks,
Amrish
You are installing the plugin twice (lines 15, 29):
Plugin 'The-NERD-Commenter'
Plugin 'https://github.com/scrooloose/nerdcommenter.git'
From scanning the README, the scrooloose version doesn't seem to support the c shortcut, so it may be doing some blocking. Reread the documentations and choose one of the two. Post back if your problem isn't solved by one of those two actions.
UPDATE:
Okay, digging deeper. The plugin's .vim code runs the following line:
let leader = exists('g:mapleader') ? g:mapleader : '\'
In your vim try running
:echo exists('g:mapleader')
:echo 'g:mapleader'
If the mapleader exists and spits back , as expected, then we need to look for unexpected/buggy code in the plugin. If it doesn't exist or isn't , as you expect, then we know what needs to be fixed.
Can't seem to find any reason for this, but I have been using Ycm, syntastic, and all the lh- plugins with vim for a while now. In the case of lh-brackets, I used to have a problem with it generating "«»" every time it 'automatically' generated the other bracket, paren, quote, etc. But it was only happening in .vim files, so i turned it off for vim files in my vimrc. Now nothing has changed, no new scripts installed, and all of the sudden, this happens with ALL files (cpp, h, pl, py, etc). Like i said, not using heavy customization, and everything is default except the disabling of lh-brackets when editing vim files, but that has now become a hotkey since i cant use it anywhere.
My Question is this: does anyone have this or similar problem with lh-brackets, and if so, any idea how to fix it, or is there some setting I am missing?
My first thoughts are to go though and check any updated vim scripts (this just happened a day ago) that could have been updated when doing an apt-get upgrade (like debian.vim) but after that I've got nothing...
The placeholders characters can be jumped to (:h <Plug>MarkersJumpF -> <C-J> with vim, <m-ins> with gvim). That's their purpose.
If you have installed lh-cpp, see :h lh-cpp-first-steps, you'll find a quick guide to my C++ suite (and lh-brackets incidentally).
EDIT: The plugin was badly designed. I've patched the plugin to rely on g:usemarks in order to fix the ergonomic of plugin .
In the (now-) past, if you wanted to set b:usemarks to 0, you'd have needed to add an autocommand that'd set b:usemarks to 0 in all new buffers.
Now, (lh-brackets v2.2.0), if you want to always disable the placeholders/marker characters, you need to set g:usemarks to 0, not b:usemarks. Buffer-local variables are meant to be set from ftplugins, or tree/project-local plugins which are supported thanks to plugins like local_vimrc.
And as romainl has pointed out, don't hesitate to use the bug trackers, or even to contact me.
hmm found it:
:let b:usemarks=0
now needs to be set, apparently that was a marker for integration to another plugin, though i dont use it.
I'm reinstalling everything after a hdd failure on my netbook (fresh install of Ubuntu Netbook Edition 10.04), and am trying to get the excellent SLIMV working again.
It was working fine on the previous installation, but with this one, parenthesis matching works, but auto-indenting Lisp code does not. Hitting return starts the cursor back in column 1 of the next line, no matter where it is in the nested parens.
I've been digging through the docs to see if there's a commandline or .vimrc switch that needs to be activated to enable indention, but don't see anything.
Am I just missing it? Any suggestions appreciated.
Check that function SlimvIndent is defined by calling :echo SlimvIndent(lnum) where lnum is the line number to be indented. It should return the indentation value for the line.
Check that lisp mode is off with the :verbose set lisp? command, that also prints the location where this option was last set. It should be "nolisp", otherwise the default lisp indenting is used by Vim.
Check that Slimv's indentation is set with the :verbose set indentexpr? command. It should be "SlimvIndent(v:lnum)".
Some indentation methods work only if Slimv is connected to the Swank server, because it needs runtime information about the form to be indented (e.g. macro definition with &body argument).
Make sure you use the latest Slimv version (0.8.4 at the moment), because it has indentation related bugfixes.
Do not checkout the Slimv repository right into the vimfiles directory, because files in the .hg directory may interfere with the Slimv installation. Checkout the files to somewhere else instead and copy only the Slimv files into vimfiles.
If you still have problems with making the indentation work, then drop me a mail and we can discuss the additional steps. I'm the author of Slimv, you can find my email address in the documentation or on my vim.org page.