Christian Brabandt wrote:
> > > Bram,
> > > it has been mentioned, that the OptionSet autocommand is not triggered,
> > > for setwinvar() function calls. Reason is, the setwinvar() function
> > > calls switch_win() to switch to the window which will block
> > > autocommands.
> > >
> > > Therefore here is a patch, that unblocks the autocommands, if an
> > > optionset autocommand is defined and while I was there, I also made the
> > > swich_win() function only trigger, if it will actually needs to change
> > > windows or tabpages.
> > >
> > > Attached is the patch, including a test.
> >
> > I'm not sure it is such a good idea to trigger OptionSet when setting an
> > option in another window. It may have nasty side effects.
>
> Yes true. Especially since this may be evaluated in the wrong
> buffer/window.
>
> > Perhaps we should document how this works, and suggest using WinEnter to
> > check option values when needed?
>
> Like this?
> diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
> --- a/runtime/doc/eval.txt
> +++ b/runtime/doc/eval.txt
> @@ -5646,6 +5646,9 @@ settabwinvar({tabnr}, {winnr}, {varname}
> :call settabwinvar(1, 1, "&list", 0)
> :call settabwinvar(3, 2, "myvar", "foobar")
> < This function is not available in the |sandbox|.
> +
> + When setting options using |:let-&|, won't trigger the
> + |OptionSet| autocommand, to avoid nasty side effects.
I was thinking of still doing it for the current window, since
":let &option = val" is equivalent to ":set option=val".
If someone doesn't want this prepend ":noau".
> > > Another question has been raised. Sometimes options will get set
> > > directly (e.g. diffmode). Should those place converted to use the
> > > set_option_...() so that the autocommand is triggered? Currently, using
> > > :diffthis does not trigger the autocommand. If so, should it be
> > > triggered only for setting the diffmode or for every setting?
> >
> > This whole code needs to be cleaned up. We should consistently use the
> > code that checks the new value and takes care of side-effects, no matter
> > what command was used to set the option. Except for the first
> > initialization.
>
> Might be a good Google Summer of Code project?
If we ever find mentors...
> > Also ":set all&" should work differently.
>
> Why? Is anybody actually using this?
Probably not, but it should work like setting each option back to its
default value, including all the side effects.
--
hundred-and-one symptoms of being an internet addict:
19. All of your friends have an @ in their names.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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.
