From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.bugs Subject: Re: bug#347: C mode asks twice about local variables Date: Mon, 9 Jun 2008 14:36:51 +0000 Message-ID: <20080609143651.GA6098@muc.de> References: <20080601172143.GA5899@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1213020965 1872 80.91.229.12 (9 Jun 2008 14:16:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Jun 2008 14:16:05 +0000 (UTC) Cc: bug-cc-mode@gnu.org, bug-gnu-emacs@gnu.org, 347@emacsbugs.donarmstrong.com To: Stefan Monnier , Glenn Morris Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Mon Jun 09 16:16:47 2008 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by lo.gmane.org with esmtp (Exim 4.50) id 1K5iAj-0002C2-VA for sf-cc-mode-help@m.gmane.org; Mon, 09 Jun 2008 16:16:34 +0200 Original-Received: from sc8-sf-list1-new.sourceforge.net (sc8-sf-list1-new-b.sourceforge.net [10.3.1.93]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 8B747F5A9; Mon, 9 Jun 2008 07:15:44 -0700 (PDT) Original-Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1K5i9u-000299-Rr for cc-mode-help@lists.sourceforge.net; Mon, 09 Jun 2008 07:15:42 -0700 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1K5i9t-0003Lw-At for cc-mode-help@lists.sourceforge.net; Mon, 09 Jun 2008 07:15:42 -0700 Original-Received: from mx10.gnu.org ([199.232.76.166]:52398) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1K5i79-0003nq-NP for bug-cc-mode@gnu.org; Mon, 09 Jun 2008 10:12:51 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1K5i8y-0000V4-Pg for bug-cc-mode@gnu.org; Mon, 09 Jun 2008 10:14:50 -0400 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on monty-python X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=unavailable version=3.1.0 Original-Received: from colin.muc.de ([193.149.48.1]:2438 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K5i8x-0000Ud-Jl for bug-cc-mode@gnu.org; Mon, 09 Jun 2008 10:14:44 -0400 Original-Received: (qmail 64499 invoked by uid 3782); 9 Jun 2008 14:14:41 -0000 Original-Received: from acm.muc.de (pD9E23E6E.dip.t-dialin.net [217.226.62.110]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 09 Jun 2008 16:14:38 +0200 Original-Received: (qmail 6433 invoked by uid 1000); 9 Jun 2008 14:36:51 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 1.0 FORGED_RCVD_HELO Received: contains a forged HELO X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: cc-mode-help-bounces@lists.sourceforge.net Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:5194 gmane.emacs.bugs:18302 Archived-At: Hi, Stefan and Glenn, On Tue, Jun 03, 2008 at 02:40:29AM -0400, Stefan Monnier wrote: > > 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? > > 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. More importantly, the value ":safe" is non-portable (to earlier Emacsen, or to the other one), and doesn't feel at all safe. I'd have to emulate, to some extent, the processing of `enable-local-variables' inside CC Mode code, and this variable gives the distinct feeling of not yet having reached its final definition. And I'd almost certainly get this wrong, either causing lots of bug reports for the failure of LV handling or leaving a security hole for unsafe variables. The right thing is to increase the granularity of control over the Local Variables handling. In particular, to have a new hook called just after parsing the local variables, but before setting them. I think it should look like this: ######################################################################### (defvar before-hack-local-variables-hook nil "Normal hook run before setting a file's local variables. This hook is called only when there is at least one local variable to set. At the time of call, the content of the \"-*-\" line at the top of the buffer and of any \"Local Variables\" section have been parsed, respectively in the two dynamically bound variables `hack-variables-on-prop-line' and `hack-variables-in-list'. Each of these is an alist with elements of the form (VAR . VALUE), VAR being the name of the variable to set and VALUE the raw string representation of its value. The elements are in the same order as in the buffer. A hook function may change the value of either of these alists. Point is at the start of the line with \"Local Variables\", or at the beginning of buffer if there is no such line.") ######################################################################### What do you think? > Stefan -- Alan Mackenzie (Nuremberg, Germany). ------------------------------------------------------------------------- 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