tplugin_vim icon indicating copy to clipboard operation
tplugin_vim copied to clipboard

VimEnter not parsed correctly with vim-autoclose plugin / first BufEnter autocmd missed?!

Open blueyed opened this issue 14 years ago • 5 comments

I've run into a problem, where s:ScanSource appears to fail.

The line in question comes from the autoclose plugin [1].

It originally reads as: autocmd BufNewFile,BufRead,BufEnter * if !<SID>IsLoadedOnBuffer() | call <SID>CreateMaps() | endif

I have added VimEnter to the end of the autogroups list, but tplugin did not handle it properly. autocmd BufNewFile,BufRead,BufEnter,VimEnter * if !<SID>IsLoadedOnBuffer() | call <SID>CreateMaps() | endif

While it gets matched by the "if" (https://github.com/tomtom/tplugin_vim/blob/master/autoload/tplugin.vim#L328), ml looks like this when playing it through manually.

Note that I have added another echom "ENTER" to the command for debugging, this should not make a difference. Maybe the issue is

0. autocmd BufNewFile,BufRead,BufEnter,VimEnter * echom "ENTER" | if !<SID>IsLoadedOnBuffer() | call <SID>CreateMaps() | endif
1.
2. BufEnter,
3. 
4. *
5.
6. echom "ENTER" | if !<SID>IsLoadedOnBuffer() | call <SID>CreateMaps() | endif

My guess is that the building of ml needs to get fixed.

Apart from that I wonder if it shouldn't work without any VimEnter autocmd? The problem appears to be that the first buffer after starting Vim appears to fire the Buf* events too early?!

1: https://github.com/Townk/vim-autoclose/blob/master/plugin/autoclose.vim#L461

blueyed avatar Mar 22 '11 14:03 blueyed

The problem seems to be that the plugin doesn't define its own augroup. This is a requirement for tplugin calling the right VimEnter autoclose. Wrapping the autocommands in :augroup AutoClose ... :augroup END should solve this issue.

tomtom avatar Mar 22 '11 19:03 tomtom

Yes, adding an augroup fixes this the parsing/execution of VimEnter.

But it does not fix the problem at hand here: for the first buffer (or rather when TPlugin autoclose gets called) the Buf* autocommands (BufEnter, BufNewFile and BufRead) do not get triggered.

Looks to me like "TPlugin" should trigger these events for the current buffer?

I do not know if that will fix it when using "TPlugin" in vimrc, but would probably work if calling TPlugin manually.

blueyed avatar Mar 23 '11 09:03 blueyed

btw: I've forked the plugin at https://github.com/blueyed/vim-autoclose and improved it some. You may be interested to try it out, not just for debugging or fixing it, but also because I find it very useful.. :)

blueyed avatar Mar 23 '11 09:03 blueyed

I'm afraid that calling Buf* autocommands and maybe others would make the whole thing rather complex. I also don't think that it would be that useful to support all events. BufRead events are usually used to set an option that is used when actually reading the file. This has already happened when loading a plugin. I think it would be tricky to find out which events to simulate for a particular buffer, wouldn't it? The BufEnter event would probably be save.

tomtom avatar Mar 23 '11 17:03 tomtom

If the BufEnter event seems safe, do you plan to add support for scanning it?

Do you see any other way the plugin in question (vim-autoclose) might get changed/improved? It is using the BufEnter event to setup mappings and configuration (into buffer local vars). Regarding the values, I've thought already to use getters (which would look for b: vars, then g: and then defaults) for this in general, and not setup "b:*" variables always. I really would appreciate your feedback on this.

Thanks.

blueyed avatar Mar 24 '11 13:03 blueyed