Re: Capturing setting ro/noro

On 2015-02-26 21:07, Christian Brabandt wrote:
>> :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?
>
> I would say, it should only trigger once.

While I prefer this for simplicity, it does mean that it becomes
difficult (if not impossible) to watch a setting that gets cascaded.
If I want to know when 'cpoptions' changes, and someone issues a
":set cp', it will change my 'cpoptions', but fire a "hey, 'cp'
changed", leaving me to store and compare the value for
'cpoptions' (or any of the other 40+ settings listed at ":help
'cp'")

If vim offers some variables for before/after inspection (I'd claim
it only needs one, depending on whether this is an OptionSetPre or
OptionSetPost sort of thing, as one of the before/after variables
would be the setting value itself), this trickle-down wouldn't work,
as the changed item would be described as "compatible" rather than
"cpoptions", and its values would be True/False rather than the
before/after values of 'cpoptions'

>> 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
>
> That shouldn't be a problem, since autocommands do not nest by
> default.

Okay, I'm cool with "this breaks things, don't do that", much like
the "WARNING: If the autocommand moves the cursor the effect of the
change is undefined" from the help.

>> You'd also have issues of option names: do you use the long or
>> short form to identify them?
>
> Well both should be unique, so the value should be matched against
> the short/long name (including prefix 'no/inv' and suffix '!')

I was presuming that the autocommand would set a pair of variables:
one to let you know which setting had changed, and one to let you
know the other (either previous or new as mentioned above) value.
The contents of the "which setting changed" would be where it would
matter. Would I test

if g:set_name=='cp' ...

or

if g:set_name=='compatible' ...

> Yes this will be tricky. If I have some time, I'll look into it.
> But note, autocommands have in the past contributed to quite some
> bugs and crashes with Vim so I can understand if Bram hesitates to
> add new ones.

I'd file the whole thing under a "nice to have", much preferring a
stable vim over one that had these features with instability.

-tim





--
--
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.