Thursday, February 26, 2015

Re: Capturing setting ro/noro

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

[1]
http://i.imgur.com/d7IwYq1.gif




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

No comments: