bug#9820: 24.0.90; Behaviour of add-file-local-variable

[Jambunathan K]

24.0.90; Behaviour of add-file-local-variable

Transcripts of exchanges on emacs-devel.
http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00850.html
http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00867.html

Additional note: All other file-local related commands may have to be
audited for the requested behaviour.

From: Jambunathan K <kjambunathan@gmail.com>
Subject: Re: Behaviour of add-file-local-variable?
Newsgroups: gmane.emacs.devel
To: Juri Linkov <juri@jurta.org>
Cc: emacs-devel@gnu.org
Date: Thu, 20 Oct 2011 09:51:36 +0530 (1 day, 45 minutes, 50 seconds ago)
Message-ID: <81fwioqomn.fsf@gmail.com>
Mail-Followup-To: Juri Linkov <juri@jurta.org>, emacs-devel@gnu.org

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?

-- 


From: Nix <nix@esperi.org.uk>
Subject: Re: Behaviour of add-file-local-variable?
Newsgroups: gmane.emacs.devel
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Juri Linkov <juri@jurta.org>, emacs-devel@gnu.org
Date: Fri, 21 Oct 2011 01:01:10 +0100 (5 hours, 5 minutes, 8 seconds ago)
Message-ID: <87y5wfmcvt.fsf@spindle.srvr.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)



In GNU Emacs 24.0.90.1 (i386-mingw-nt5.1.2600)
 of 2011-10-19 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.6) --no-opt --cflags -I"C:/Program 
Files (x86)/GnuWin32/include" -ID:/devel/emacs/libXpm-3.5.8/include 
-ID:/devel/emacs/libXpm-3.5.8/src -ID:/devel/emacs/gnutls-2.10.5-x86/include 
--ldflags -LD:/devel/emacs/gnutls-2.10.5-x86/lib'