When your plugin wants to provide an event the user can hook into, it could
broadcast a User autocommand:
function! foo#do_it()
call s:do_thing()
doautocmd User FooDidIt
endfunction
If the user's vimrc contains,
augroup MyGroup
autocmd!
autocmd User FooDidIt call MyHandler()
augroup END
then MyHandler() will be called any time foo#do_it() runs.
If the user *does not* set up any such autocommand, however, any time
foo#do_it() runs, Vim displays "No matching autocommands".
You could suppress these messages by prefixing doautocmd with "silent", but
that would also suppress any messages a handler tries to display. So most
plugins wrap doautocmd in a conditional:
function! foo#do_it()
call s:do_thing()
if exists('#User#FooThing')
doautocmd User FooThing
endif
endfunction
When providing an event the user can hook into, I'd think it's better to
decouple the plugin from any knowledge/concern about what, if anything, has
been set up to listen for the event. But we're forced to run this check, given
how doautocmd works.
More importantly, the exists() check is inaccurate in some cases. For example,
the following are two autocommand definitions are equivalent,
autocmd User FooBar,FooBaz call MyHandler()
autocmd User Foo{Bar,Baz} call MyHandler()
but exists('#User#FooBar') will return true for the first and false for the
second.
I can see the usefulness of displaying No matching autocommands for debugging
purposes, but beyond that it seems like bad behavior.
Am I thinking about this the wrong way?
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
