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

[Jambunathan K]

Juri Linkov <address@hidden> 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?

--