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

If the user's vimrc contains,

    augroup MyGroup
      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

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 

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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui