Re: Problematic doautocmd behavior

2018-04-15 Fir de Conversatie Bram Moolenaar
Ivan Brennan wrote: > 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

Re: Problematic doautocmd behavior

2018-04-14 Fir de Conversatie Christian Brabandt
On Sa, 14 Apr 2018, Ivan Brennan wrote: > I'm curious how difficult it would be to change the implementation of > doautocmd, but since I'm not about to try myself I won't dwell on it any > further :) That should be rather easy. Something like this I believe: diff --git a/src/ex_docmd.c

Re: Problematic doautocmd behavior

2018-04-14 Fir de Conversatie Ivan Brennan
That's a good point. Given the choice between: a) unintentionally silencing messages that a hook tried to display and b) failing to trigger an autocommand because it was defined using a pattern construct that exists() fails to recognize I'll opt for (a). I'm curious how difficult it

Re: Problematic doautocmd behavior

2018-04-14 Fir de Conversatie Ingo Karkat
On 14-Apr-2018 20:39 +0200, Christian Brabandt wrote:  > > On Sa, 14 Apr 2018, Ivan Brennan wrote: > >> 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

Re: Problematic doautocmd behavior

2018-04-14 Fir de Conversatie Christian Brabandt
On Sa, 14 Apr 2018, Ivan Brennan wrote: > 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, >