Capturing setting ro/noro

[Axel Bender]

Is there a way to capture the setting of readonly? I.e. I'd like to be able to inject a function when the readonly setting is changed.

[Ben Fritz]

On Wednesday, February 25, 2015 at 3:57:57 AM UTC-6, Axel Bender wrote:
> Is there a way to capture the setting of readonly? I.e. I'd like to be able to inject a function when the readonly setting is changed.

No, you cannot detect when arbitrary options change.

You could monitor for an option change in a CursorHold event, maybe even combined with CursorMoved, etc.

But readonly will only change automatically when reading the file. So is BufReadPost sufficient for your needs? Why do you need to detect when the value changed?

For all these methods, you can read the current value with something like:

:let current_readonly = &readonly

[Axel Bender]

I'd like to set the editor's background whenever I switch to/read a RO file, or when I set the readonly option.

Right now I'm "abusing" statusline for my needs; it works pretty good but it is also pretty "dirty"...

[Ben Fritz]

On Wednesday, February 25, 2015 at 10:50:38 AM UTC-6, Axel Bender wrote:
> I'd like to set the editor's background whenever I switch to/read a RO file, or when I set the readonly option.
>
> Right now I'm "abusing" statusline for my needs; it works pretty good but it is also pretty "dirty"...

For that use, a BufEnter autocmd is probably sufficient, combined with CursorHold for when you set the option manually.

[Axel Bender]

I had to dismiss a solution based on CursorHold as it isn't immediate. Sadly there is no ReadonlyChanged event...

[Axel Bender]

On Thursday, February 26, 2015 at 9:11:35 AM UTC+1, Axel Bender 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?

[Christian Brabandt]

I would rather add a new autocommand au Option or au OptionSet

Best,
Christian

[Axel Bender]

@Christian

Correct me, if I get sth wrong here, but autocommands are based on events? How would I implement e.g. a "ReadonlyChanged" with other events?

[Tim Chase]

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

[Salman Halim]

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

[David Fishburn]

Yes, if it is a list I would want to see:

1.  current value  

2.  previous value

Whether this event fires before or after the option is actually changed.

In that list it would nice to have what triggered the option setting.  Not sure how we would describe that, maybe the statement itself "set cp" or some enumeration of it.

David

[Christian Brabandt]

Hi Tim!

On Do, 26 Feb 2015, Tim Chase 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?

I would say, it should only trigger once.

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

>
> 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 '!')

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

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.

Best,
Christian
--
Es ist schon komisch, daß ein Mann, der sich um nichts auf der Welt
Sorgen machen muß, hingeht und eine Frau heiratet.
-- Robert Lee Frost

[Christian Brabandt]

Hi Axel!

I do not understand the question.

Best,
Christian
--
Es gibt nur ein Elend, und das ist Unwissenheit.
-- Thornton Niven Wilder

[Tim Chase]

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