Re: Capturing setting ro/noro

On Feb 26, 2015 11:36 AM, "Tim Chase" <vim@tim.thechases.com> wrote:
>
> On 2015-02-26 12:01, Christian Brabandt wrote:
> > >> I had to dismiss a solution based on CursorHold as it isn't
> > >> immediate. Sadly there is no ReadonlyChanged event...
> > >
> > > Where in the sources would I start btw. if I wanted to implement
> > > a new event?
> >
> > I would rather add a new autocommand au Option or au OptionSet
>
> I second Christian's suggestion, making it more generic.  There are
> times I've wanted to catch changes in other settings (mostly for
> debugging purposes), and a broader OptionSet event with some variable
> containing the option name, the old value, and the new value.
>
> Though this would get particularly hairy for settings that impact
> other settings such as
>
>   :set cp
>
> which changes a whole bunch of other settings.  Does one just fire a
> single "OptionSet", or does one then cascade the firing of more
> "OptionSet" events for the ~48 settings it would impact?
>
> Then you also have "useless machine"[1] cases where the code fired on
> the event re-sets the option back to its previous state:
>
>   :autocmd OptionSet * if g:option_name=='expandtab'|set et|endif
>
> You'd also have issues of option names:  do you use the long or short
> form to identify them?
>
> It's a big ugly can of worms, and while I'd enjoy seeing the
> functionality come to Vim, I'd rather it be done "right".
>
> -tim
>

I think that a second event fires after 'cp' is changed, but without some indication that it's a secondary reaction or some such, people will go mad trying to find out how the option was triggered. I would consider such a thing to be a single operation and create one event and have the variable be a list of all options.

Maybe also indicate the old value in there?

I'm not too worried about the useless case because I can already, in a WinLeave, go back to the window that was left, so this already exists. Alternatively, you could sandbox this event so you can't reset any options in the list of options that triggered this event.

I can also see the case where this event could be fired recursively with two listeners that listen to options A and B and keep resetting options B and A, respectively. So, maybe the sandbox would have to be limited on whether settings within the listener trigger further events.

Salman

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.