Closed wimstefan closed 7 years ago
I cannot reproduce your problem. Have you tried using the minimal vimrc
suggested in the documentation, or are you using your own vimrc
? There might be a conflict with some plugin.
If there's another option to achieve that I'll drop 'c-n' in a second since it causes quite some lag ;-)
You may find the section “Optimize your completion chains” in :h mucomplete-tips
helpful.
And if you have used the vimrc
from the documentation, you may try with this one instead:
if has('packages')
set packpath=
endif
set runtimepath=/path/to/mucomplete/ # CHANGE THIS
set completeopt=menu,preview,menuone,noinsert,noselect
set showmode shortmess-=c
set spell
set spelllang=nl,en,de,es
let g:mucomplete#chains = {'vim': ['path', 'cmd', 'c-n'], 'default': ['path', 'omni', 'user', 'c-n', 'dict']}
which really makes sure that the only loaded plugin is µcomplete.
Yes I tried it yesterday night with only the minimal vimrc you have in the help text as I wrote above. And it works with the minimal vimrc but not with my customized vimrc with other plugins in it. Sorry for not being very clear :confounded: So it has to be a problem with one of the other plugins that started since yesterday ...
I'll go and see if I can find the culprit and report back.
Regarding the alternatives for 'c-n'
: I've read the section "Optimize your complete chains" many times but I didn't understand it good enough to make completion from other buffers working without using 'c-n'
or 'c-p'
. It might be written clear in the help and I'm just not understanding it well enough.
I'll go and see if I can find the culprit and report back.
Ok, it would be good to know what plugin causes trouble.
Regarding optimizing keyword completion: you have spell
set and kspell
in complete
. That means that Vim collects keywords from the current spelling dictionary during keyword completion. You may try this instead:
set complete-=kspell
let g:mucomplete#chains = {'default': ['path', 'omni', 'user', 'c-n', 'uspl', 'dict']}
By doing so, the spelling dictionary will be searched only if 'c-n'
, and the methods before it, fail to return any result. This should speed up things a bit.
Found it!!! It is tpope/vim-rsi which is causing the trouble. It was quite a hassle to find it - I used your minimal vimrc and added one of plugins per time to the rtp starting with the latest modified ones. After half an hour I reached vim-rsi which wasn't touched since October 2016 but still is in the way as it seems ;-)
Oh and thanks for the tip about the keyword completion - after disabling set complete+=kspell
in my config things are faster now indeed. And I think I understand correctly now after reading it 5 times more that I really have to use 'c-n'
for completing keywords from other buffers ;-)
Thanks a lot for your time and efforts!
Ok, I was able to reproduce the problem with rsi installed. That is a regression introduced by a recent change in µcomplete. I plan to fix it soon.
@wimstefan Please try the current master, and feel free to reopen the issue if necessary.
The newline is gone now indeed. Thanks for that!
But now some of the completion methods (uspl, dict, omni, complete) stopped working. And completion for keywords in the same file as well. Only 'path' and 'user' are still available with
My settings:
set complete=.,w,b,u
set completeopt=menu,preview,menuone,noinsert,noselect
let g:mucomplete#enable_auto_at_startup = 1
let g:mucomplete#chains = { 'default': ['path', 'omni', 'user', 'c-n', 'dict']}
Please try 8662f95. There was a typo in 8d448cc.
All seems to be fine except that I had to re-enable set complete+=kspell
to get spelling working ...
I need to investigate this further. I am reopening this.
Are you sure you have set spell
?
I thought I did but apparently not since now it works with 2 buffers and set spell
and set complete-=kspell
... I am very sorry for the noise and confusion :confounded:
Right now all seems to be working just fine for me. Thanks so much for the swift reaction and patience!!! :+1:
As of now, having both vim-rsi and mucomplete installed causes the following to be echoed when you enter "o" to insert a newline:
[MUcomplete] <c-e> is already mapped. Use :verbose imap <c-e> to see where it is mapped.
[MUcomplete] NOTE: since v1.0.0, you do not need to map <c-e> in your vimrc any longer.
Would you mind opening an issue about that? Probably, vim-rsi maps CTRL-E in Insert mode.
So, I've taken a look: vim-rsi maps <c-e>
in Insert mode. To get rid of MUcomplete's warning, you may add these lines to your vimrc
:
let g:mucomplete#no_popup_mappings = 1
imap <c-y> <plug>(MUcompletePopupAccept)
imap <cr> <plug>(MUcompleteCR)
The first line wil prevent MUcomplete from mapping <c-e>
, <c-y>
and <cr>
. The other two lines recover the functionality of <c-y>
and <cr>
. With this setup, MUcomplete will work as usual, except that you will have to press <c-e>
twice to cancel a pop-up menu.
Unfortunately, vim-rsi does not use plugs and does not check whether a mapping is already defined. Instead, it silently overrides an existing mapping. Maybe, that should be reported to vim-rsi's repo.
For bug reports only, please provide the following details:
:help mucomplete-troubleshooting
.echo g:mucomplete#chains
:{'vim': ['path', 'cmd', 'c-n'], 'default': ['path', 'omni', 'user', 'c-n', 'dict']}
setl completeopt
:completeopt=menu,preview,menuone,noinsert,noselect
.vimrc
, if any:let g:mucomplete#chains = {'vim': ['path', 'cmd', 'c-n'], 'default': ['path', 'omni', 'user', 'c-n', 'dict']}
If your problem has to do with specific completion methods, please provide the output of the relevant settings (choose all that apply):
'c-n'
,'c-p'
,'line'
)setl ft cpt inc pa dict tsr spell? spl tags
andecho tagfiles()
setl output:echo tagfiles():
[]
Using to call mucomplete. I need one of those chains because otherwise keywords from other buffers are not included. If there's another option to achieve that I'll drop
'c-n'
or'c-p'
produces a newline before every suggestion as soon as I type'c-n'
in a second since it causes quite some lag ;-)