Changing variables has no effect on functionality of the plugin about auto-pairs HOT 8 CLOSED

This wouldn't happen to occur exclusively in Rust files, would it?

from auto-pairs.

It happens in all files, I tried any kind of binds, even like 'c':'v' in both .vim and .tex files (without specifying any filetype in the AutoPairsDefine function).

SpaceVim lets you create a function, in which you write all of your vimrc config lines, which is called on autocmd VimEnter [I'm not a fan of this but it seems to be the only way to set vimscript commands]. Is it possible that this is too late for AutoPairs?

from auto-pairs.

Seems that that was the problem, I can set AutoPairs settings in another function which is called earlier on and the settings now stick. Only problem is that the function AutoPairsDefine isn't defined yet, so setting the variable manually works but doing it through the function doesn't. I'll explore this further and inform you, might be nice to have in the documentation in case someone else is running a similar setup

from auto-pairs.

Strange.

Is it possible that this is too late for AutoPairs?

Only if it happens after buffer creation, but you wouldn't see that if you open a new buffer while Vim is already running. I'm not entirely sure when the autocmd executes relative to buffer creation though, but it'd only affect the first thing you edit after opening vim at worst.

b:AutoPairs, which actually contains the pairs used, is created from g:AutoPairs, and is then used to populate another internal variable I don't remember the name of, but it doesn't matter in this case. As you've described it, and from the little I looked at spacevim's source code, no buffer variable modification is involved, so b:AutoPairs is indicative on its own. This also means g:AutoPairs has to be defined before b:AutoPairs is created, hence why order is potentially significant.

What's the output of :verbose imap c (or any other key you have mapped), and :echo b:AutoPairs?

Only problem is that the function AutoPairsDefine isn't defined yet, so setting the variable manually works but doing it through the function doesn't.

As long as the plugin has been loaded by the time your code executes, it's fine. This fork uses autoload functions, so calling autopairs#AutoPairsDefine() makes Vim automatically load the file to avoid the undefined functions that plagued the original auto-pairs.

from auto-pairs.

Good point on buffer creation. Setting the variable in the "after" bootstrap function, which is called on VimEnter apparently, has no effect on the mappings at first. After opening a new .tex file in a new buffer I get this

i  c           *@<C-R>=autopairs#AutoPairsInsert('c')<CR>
        Last set from ~/.cache/vimfiles/.cache/init.vim/.dein/autoload/autopairs.vim line 556

as the output of :verbose imap c and all mappings work as expected.

from auto-pairs.

So it's an init order problem causes by spacevim's config style? Not really much to document here then; would probably be good if spacevim added some more hooks though

from auto-pairs.

Yeah kinda annoying but it isn't too much of a big deal. For now I've set my personal config file to also be called on BufEnter instead of VimEnter, it doesn't seem to cause any problems in my use case and everything works perfectly. I was wondering if I could set the necessary AutoPairs functions to also be called once on VimEnter (obviously not by default in the plugin but only for my config) since it seems like it would be lighter than calling my own config on BufEnter every time, but I couldn't find out how/ when this happens by looking at the plugin code.

It would be nice to try out this alternative solution if possible, if not I'd close this issue as we've figured out what causes it and I've managed to make it work in my specific case.

from auto-pairs.

As a last option though, if you have a way to inject stuff early, you can take advantage of the init hook to initialise variables that way:

I recommend some access control variable though (or possibly checking if !exists("g:AutoPairsLoaded") (or a custom variable) to determine whether or not to load the variables, but that still requires it to be compatible with spacevim's control flow.

from auto-pairs.