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 19:07:50 +0000 Message-ID: <20080609190750.GC6098@muc.de> References: <20080601172143.GA5899@muc.de> <20080609143651.GA6098@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 1213037178 30952 80.91.229.12 (9 Jun 2008 18:46:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Jun 2008 18:46:18 +0000 (UTC) Cc: bug-cc-mode@gnu.org, Glenn Morris , bug-gnu-emacs@gnu.org, 347@emacsbugs.donarmstrong.com To: Stefan Monnier Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Mon Jun 09 20:46:58 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 1K5mOD-00017W-Vn for sf-cc-mode-help@m.gmane.org; Mon, 09 Jun 2008 20:46:46 +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 89C39FD3E; Mon, 9 Jun 2008 11:45:56 -0700 (PDT) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1K5mNP-00048x-4h for cc-mode-help@lists.sourceforge.net; Mon, 09 Jun 2008 11:45:55 -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 1K5mNO-0003RH-Ke for cc-mode-help@lists.sourceforge.net; Mon, 09 Jun 2008 11:45:55 -0700 Original-Received: from mx10.gnu.org ([199.232.76.166]:52024) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1K5mLK-0006fg-Gv for bug-cc-mode@gnu.org; Mon, 09 Jun 2008 14:43:46 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1K5mNB-00037x-1T for bug-cc-mode@gnu.org; Mon, 09 Jun 2008 14:45:46 -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]:2656 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 1K5mNA-00036x-8s for bug-cc-mode@gnu.org; Mon, 09 Jun 2008 14:45:40 -0400 Original-Received: (qmail 19320 invoked by uid 3782); 9 Jun 2008 18:45:37 -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 20:45:34 +0200 Original-Received: (qmail 10324 invoked by uid 1000); 9 Jun 2008 19:07:50 -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:5196 gmane.emacs.bugs:18307 Archived-At: Hi, Stefan! On Mon, Jun 09, 2008 at 11:18:28AM -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? > Any comment about this suggestion? YUCK!!! ;-) I don't know off-hand what the significance of buffer locality is in CC Mode styles. But trying to get a "don't override" parameter to work would be horrendous. hack-local-variables is actually called after the language hook, isn't it? By that time, the CC Mode style will already have been set, and the pertinent variables will already be buffer local. At least I think so. > >> > 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. What I had in mind was using an (if (boundp 'before-hack-local-variables) ...) to separate out new strategy from old. > > 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. At some stage, maybe, perhaps, another option, single:, will come into being. This will mean "prompt for each non-safe variable individually". Explicitly setting `enable-local-variable' in CC Mode will couple CC Mode very strongly to files.el. That's not a good thing. > > (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. Actually, it's a lot simpler than I expectied. We can use the already read (as in lisp read) version of variables' values and we needn't separate out the "-*-" values from the "Local Variables:" values. In that case, the entire change to `hack-local-variables' would be: (i) Rename `result' to `hack-local-variables-alist'. This variable contains the spec of all local variables as an alist, and would be available to hook functions for manipulation. (ii) Insert this single line of code: ;; We've read all the local variables. Now, return whether the ;; mode is specified (if MODE-ONLY is non-nil), or set the ;; variables (if MODE-ONLY is nil.) (if mode-only result (run-hooks 'before-hack-local-variables-hook) ; <============= NEW LINE (dolist (ignored ignored-local-variables) (setq hack-local-variables-list (assq-delete-all ignored hack-local-variables-alist))) The new hook function in CC Mode (which would supersede the old one for Emacs 23 (?or 22.3?)) would be this: (defun c-before-hack-hook () "Doc string." (let ((stile (cdr (assq 'c-file-style hack-local-variables-list))) (offsets (cdr (assq 'c-file-offsets hack-local-variables-list)))) (when stile (or (stringp stile) (error "....")) (c-set-style stile)) (when offsets (mapc (lambda (langentry) (let ((langelem (car langentry)) (offset (cdr langentry))) (c-set-offset langelem offset))) offsets)))) This would replace ~90 lines of existing code (once Emacs 22 has fallen into desuetude). Oh, and the hook would need documenting in the Elisp manual, but I can manage that. Hey, this is so easy and obviously the right thing. Let's do it! > 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