unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: bug-cc-mode@gnu.org, Glenn Morris <rgm@gnu.org>,
	bug-gnu-emacs@gnu.org, 347@emacsbugs.donarmstrong.com
Subject: Re: bug#347: C mode asks twice about local variables
Date: Mon, 09 Jun 2008 11:18:28 -0400	[thread overview]
Message-ID: <jwvr6b6r6ci.fsf-monnier+emacsbugreports@gnu.org> (raw)
In-Reply-To: <20080609143651.GA6098@muc.de> (Alan Mackenzie's message of "Mon,  9 Jun 2008 14:36:51 +0000")

>> > Yes.  This needs fixing, somehow.
>> 
>> > The way this happens is that in a C file's local variables list, there
>> > are two "special" variables, e.g. `c-file-style'.
>> 
>> > When 
>> 
>> >     c-basic-offset: 11
>> >     c-file-style: "k&r"
>> 
>> > occurs in the local variable list, this triggers a hook function
>> > which calls (c-set-style "k&r").  The hook is
>> > hack-local-variables-hook.  The problem is that this c-set-style call
>> > will overwrite the explicit value for c-basic-offset.  The explicit
>> > value MUST take precedence here.
 
>> Can you try and call `c-file-style' with some extra "don't override"
>> (when called from that hack-local-variables-hook) argument so that any
>> variable that already has a buffer-local binding will not be
>> overridden?

Any comment about this suggestion?

>> > My solution was to call hack-local-variables a second time from
>> > within the hook function, first having deleted any occurrences of
>> > `mode', `c-file-style' etc. from the Local Variables.  This kludge
>> > worked reasonably well until the handling of
>> > safe/dangerous-local-variables was changed for Emacs 22.

>> How 'bout wrapping the call inside (let ((enable-local-variables
>> :safe))?

> I've been thinking this over.  It's not the right solution.  For a start,
> the second call to `hack-local-variables' is in itself a kludge.

I'd tend to agree, but "kludge" fixes the problem, it's still better
than the current "same kludge + problem".

> More importantly, the value ":safe" is non-portable (to earlier Emacsen,
> or to the other one),

Non-portability might indeed be a problem (tho, it's obviously "your"
problem rather than mine), but introducing a new hook in Emacs-23 won't
help you there, so it's not relevant to this discussion.

> and doesn't feel at all safe.

But I don't see why you don't consider it safe: it is really meant to be
safe, so if there's any doubt about it, we should very much address it.

> (defvar before-hack-local-variables-hook nil
[...]
> What do you think?

I'm not thrilled.  You might convince me at some point, but the kludge
doesn't look nearly as bad when compared to this hook.


        Stefan

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php


  reply	other threads:[~2008-06-09 15:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <871w1aywbx.fsf@stupidchicken.com>
2008-05-31 22:51 ` bug#343: C mode asks twice about local variables Glenn Morris
2008-06-01 17:21   ` Alan Mackenzie
2008-06-03  6:40     ` bug#347: " Stefan Monnier
2008-06-09 14:36       ` Alan Mackenzie
2008-06-09 15:18         ` Stefan Monnier [this message]
2008-06-09 19:07           ` Alan Mackenzie
2008-07-31 14:20     ` bug#347: marked as done (C mode asks twice about local variables) Emacs bug Tracking System
2008-07-31 14:20   ` bug#343: " Emacs bug Tracking System

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvr6b6r6ci.fsf-monnier+emacsbugreports@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=347@emacsbugs.donarmstrong.com \
    --cc=acm@muc.de \
    --cc=bug-cc-mode@gnu.org \
    --cc=bug-gnu-emacs@gnu.org \
    --cc=rgm@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).