b:mucomplete_chains

[Konfekt]

Define a b:mucomplete_chains variable so that for example an autocommand can add spel completion if and only if &l:spell is set.

Thanks for this great plug-in!

[lifepillar]

I was thinking about that, but I am not sure it would make a good addition. Suppose you define

let b:mucomplete_chains = { 'default': ['keyn'] }
let g:mucomplete#chains.python = ['omni', 'c-p']

and suppose that the current filetype is python. Should µcomplete use the global, Python-specific, settings, or the buffer-local default settings? Different users might have different expectations.

Also, for the use case you suggest, just simply append 'spel' to the default chain: the method won't be used is the spell option is off (that's what g:mucomplete#can_complete is for).

[Konfekt]

The buffer variable was meant as a replacement of the filetype option in the global variable, thus it would be a list and not a dictionary.

In fact, my use case is that in all text filetypes, such as mail, text, markdown, and TeX, spell is enabled. Leveraging this, I'd like to use say c-p and dict before omni, but in all other, code filetypes such as c, cpp, java, instead omni completion first. You could still enable dict completion in code filetypes, for example for editing comments, but for those, more useful is omni completion.

[Konfekt]

I thought about this a bit more. It is more of a design choice than a feature request: The idea is that g:mucomplete#chains and b:mucomplete#chains allows to replace

let g:mucomplete#chains = {
                  \ 'default':  ['file', 'c-n',  'omni']
                  \ 'c':  ['file', 'c-n', 'ulti', 'omni', 'spel']
                  \ 'java':  ['file', 'c-n', 'ulti', 'omni', 'spel']
                  \ 'perl':  ['file', 'c-n', 'ulti', 'omni', 'spel']
                  \ }

by the more concise

let g:mucomplete#chains = ['file', 'omni', 'c-n']
augroup mucomplete
  autocmd!
  autocmd FileType c,java,perl let b:mucomplete#chains = ['file', 'omni', 'ulti', 'c-n', 'dict', 'spel']
augroup END

And it offers additional flexibility, such as the mentioned

augroup mucomplete
  autocmd!
  autocmd FileType *
        \ if &l:spell && (&l:modifiable && !&l:readonly) |
        \   let b:mucomplete#chains = ['file', 'c-n', 'dict', 'spel', 'omni', 'ulti']
        \ endif
augroup END

Thus, as is, using b:mucomplete_chain and the filetype dictionary g:mucomplete#chains doubles functionality.

[lifepillar]

Yes, when I started implementing µcomplete I pondered the question of using buffer-local variables vs dictionaries with filetype-specific chains. Eventually, I went for the latter because:

1. it does not take an autocmd or a file in after/ftplugin to override the global list;
2. i didn't want to pollute theb: namespace;
3. this is what other plugins, like NeoComplete do, so it was likely familiar to users.

What you propose has the marginal advantage of simplifying the definition of g:mucomplete#chains, but it makes more complicated to override the default on per-filetype basis. So, I don't plan to change that. By introducing b:mucomplete_chain, you have all the flexibility you want. Your example is:

let g:mucomplete#chains = { 'default' : ['file', 'omni', 'c-n'] }
augroup mucomplete
  autocmd!
  autocmd FileType c,java,perl let b:mucomplete_chain = ['file', 'omni', 'ulti', 'c-n', 'dict', 'spel']
augroup END

etc…

[Konfekt]

Ok, just wanted to alert that the filetype dictionary is now redundant. But of course if that's your deliberate design choice for cited reasons, then that's fine.

[lifepillar]

As soon as I remove the filetype dictionary, I'm pretty sure that an issue will be opened :) I think it's good to give different possibilities for configuration, even if there's a bit of redundancy. Thanks for the feedback, btw!

[Konfekt]

Alright, of course there's also the question of backwards compatibility. Closing then.