I'm using Vim with EasyMotion plugin. My current .vimrc is following: https://github.com/iAdramelk/.dotfiles/blob/master/vimrc
I'd like how this plugin works, bot every time I tried to move with it it prints following message and didn't move until I hit enter:
EasyMotion: Jumping to [222, 41]
Press ENTER or type command to continue
There is no such behavior in EasyMotion demo at it's repo. So I'm assuming that there is some bug in my config. But even if I disable all plugins and set options bug still persists.
How can I fix this behavior?
Do you consume the plugin through GitHub, or an official version from the vim.org website? This looks like some debugging statement left in the plugin code.
You could work around the problem by using :silent in its mappings, or increasing 'cmdheight', but I would really contact the plugin author to fix the root cause.
Fixed bug by uninstalling vim (installed by homebrew with flag --with-features=big), and then reinstalling it from here homebrew/dupes/vim in huge configuration.
Related
VIM VERSION: VIM - Vi IMproved 8.0 (2016 Sep 12, compiled May 2 2017 03:55:34)
I'm using a number of plugins with vim in order to make things work. I install them via the package manager Vundle, my .vimrc can be found in my dotfiles repository on github
Today, I tried to edit a SASS file with vim, however - the SASS file looks like a color-circus:
I've followed some steps from this answer which include:
Does enabling syntax explicitly fix your problem? :syntax enable
Is filetype detection on? :filetype
Does vim recognize this as a sass file? :set filetype?
Check to make sure your script directories are in the runtime path :set runtimepath?
Does manually loading the syntax file change anything? :runtime! vimfiles/syntax/sass.vim
Also check if syntax highlighting works for other filetypes.
The answers to each point are:
Nothing changed, syntax remains exactly the same.
running :filetype returns filetype detection:ON plugin:ON indent:ON
running :set filetype? returns filetype=sass
running :set runtimepath? returns a long list of ~/.vim/bundle/[PATH] entries of which none include sass in any form
running :runtime! ~/.vim/bundle/vim-haml/syntax/sass.vim also changes nothing
Syntax highlighting works for everything except SASS so far.
Additionally, I've tried adding some plugins from http://vimawesome.com/.
They all seem to be packages that either support a different package which should be supported by default or they do not support SASS (in addition to SCSS) highlighting.
This is, what I came up with in the end, still making no difference:
Plugin 'tpope/vim-haml'
Plugin 'JulesWang/css.vim'
Plugin 'hail2u/vim-css3-syntax'
The plugin tpope/vim-haml however, does have a sass.vim file with it's syntax rules, it's actually the only up-to-date one compared to the rest which all seem to hang at "last updated 5+ years ago".
I basically have two questions, which I hope, more experienced vimologists will be able to answer, or point me in the right direction of fixing it myself:
Is there any known properly updated SASS (indent syntax) plugin that I missed?
If the above question is "no", then how could I get the tpope/vim-haml sass syntax file loaded for all my sass files?
I'm using SASS since, coming from Atom, it is less typing. I would prefer to keep the sass syntax if possible! (I am aware of conversion plugins but for the sake of my colleagues I would like to refrain from using any)
Thanks in advance!
Answer
It was the colorscheme I was using, it caused severe formatting issues for my SASS files.
TLDR;
I was using roosta/srcery and just tried an alternate colorscheme to test if the sass file would look more "sane", it now looks like this (using a random colorscheme):
What we see here is still not perfect, but at least "sane" (I can understand why CSS3 flex properties aren't highlighted yet for instance), I'm simply going to try inform the author of the (really nice nonetheless) colorscheme to see if he is interested in improving it for SASS.
My lesson here, is that one should look at every aspect, I was thinking in the wrong direction and kept on going for too long as a result. When #romainl pointed out it looked fine using just regular-builtin-vim I started expecting a Plugin (a colorscheme) to be the suspect which solved my issue :)
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.
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 have been using these dotfiles for my vim configuration among other things:
https://github.com/skwp/dotfiles
I recently updated the files and some of the control-p stuff has stopped working
If I select ,b I get the following error:
Not an editor command CloseSingleConque
If I look at the settings file for ctrl-p I see the following mapping:
nnoremap <silent> ,b :CloseSingleConque<CR>:CtrlPBuffer<cr>
My vim installation does not recognise CloseSingleConque. Does anybody know why this is?
Taking all your settings from random internet strangers is not a very good idea.
:CloseSingleConque<CR> is in the ruby-conque plugin that is part of this "distribution". Do you have it installed? If not, you can safely remove this part of the mapping. If it's installed, that's a bug that you should report to the author.
Take this problem as an opportunity to think again about using someone else's "distribution" versus rolling your own, progressively.
Seriously, who needs 80 plugins, including two overlapping fuzzy file/buffer navigators and another which is already bundled with Vim?