Behaviour of add-file-local-variable?

Behaviour of add-file-local-variable?

[Jambunathan K]

Should add-file-local-variable also set the variable immediately rather
than merely updating the file footer?
-- 

Re: Behaviour of add-file-local-variable?

[Juri Linkov]

> Should add-file-local-variable also set the variable immediately rather
> than merely updating the file footer?

While keeping text in the Local Variables section in sync with actual
values looks like the right thing to do, it raises related questions
that are more difficult to decide:

Should `M-x add-file-local-variable RET mode RET' also change current mode?

Should `M-x add-file-local-variable RET coding RET' also change the
current buffer coding?

Should `M-x add-file-local-variable RET eval RET' evaluate the added expression?

Should `delete-file-local-variable' return the previous buffer-local value
or revert to the global value?

Should `add-dir-local-variable' after modifying .dir-locals.el
also update values in all visited file buffers in all subdirectories?

Re: Behaviour of add-file-local-variable?

[Jambunathan K]

Juri Linkov <juri@jurta.org> writes:

>> Should add-file-local-variable also set the variable immediately rather
>> than merely updating the file footer?

> While keeping text in the Local Variables section in sync with actual
> values looks like the right thing to do, it raises related questions
> that are more difficult to decide:

If a user adds a file local variable and intends that it take
immediately what will he do? I believe he is more likely to revert the
file. Does "act-as-though-the-file-were-reverted policy" still very
difficult to deal with while applying file local variables?

Even if you insist on retaining the existing behaviour, at the minimum I
need some warning that the local variable has not kicked in. This could
be handled by

1. Updating the docstring of the above commands
2. Prompting the user whether he wants to "apply" the changes (in much
   the same way that a user is warned of risky or non-safe variables)
3. Provide a prefix modifier to the commands

(1) is the easiest way to tackle it.

Anyways, I surprised by the current behaviour and it took sometime to
figure out what's happening.

> Should `M-x add-file-local-variable RET mode RET' also change current mode?
>
> Should `M-x add-file-local-variable RET coding RET' also change the
> current buffer coding?
>
> Should `M-x add-file-local-variable RET eval RET' evaluate the added expression?
>
> Should `delete-file-local-variable' return the previous buffer-local value
> or revert to the global value?
>
> Should `add-dir-local-variable' after modifying .dir-locals.el
> also update values in all visited file buffers in all subdirectories?

-- 

Re: Behaviour of add-file-local-variable?

[Stefan Monnier]

> Even if you insist on retaining the existing behaviour, at the minimum I
> need some warning that the local variable has not kicked in. This could
> be handled by

I think that add-file-local-variable could simply check if the
variable's value is already the new one and if not output a message
along the lines "Done; revisit the file to make it take effect" (tho
"take effect" doesn't sound right: please native speakers fix it for
me).


        Stefan

Re: Behaviour of add-file-local-variable?

[Nix]

On 20 Oct 2011, Stefan Monnier stated:
> I think that add-file-local-variable could simply check if the
> variable's value is already the new one and if not output a message
> along the lines "Done; revisit the file to make it take effect" (tho
> "take effect" doesn't sound right: please native speakers fix it for
> me).

Your instincts mislead you: it's right. Perhaps a more explicit "Revisit
file to make this change take effect" would be better? (But that's
style, not grammar.)

-- 
NULL && (void)