From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Warnings about keymaps Date: Thu, 17 Sep 2009 10:02:49 -0400 Message-ID: References: <83ocph26p7.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1253196215 28982 80.91.229.12 (17 Sep 2009 14:03:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Sep 2009 14:03:35 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 17 16:03:28 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MoHa1-00067U-9X for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2009 16:03:25 +0200 Original-Received: from localhost ([127.0.0.1]:39654 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MoHa0-0001qN-Ha for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2009 10:03:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MoHZa-0001hv-LV for emacs-devel@gnu.org; Thu, 17 Sep 2009 10:02:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MoHZW-0001fo-0f for emacs-devel@gnu.org; Thu, 17 Sep 2009 10:02:58 -0400 Original-Received: from [199.232.76.173] (port=39144 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MoHZV-0001fh-Sz for emacs-devel@gnu.org; Thu, 17 Sep 2009 10:02:53 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:29050 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MoHZS-0002S1-U6; Thu, 17 Sep 2009 10:02:51 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAK/esUpFxKiJ/2dsb2JhbACBU90xhBgFh38 X-IronPort-AV: E=Sophos;i="4.44,403,1249272000"; d="scan'208";a="45861210" Original-Received: from 69-196-168-137.dsl.teksavvy.com (HELO pastel.home) ([69.196.168.137]) by ironport2-out.pppoe.ca with ESMTP; 17 Sep 2009 10:02:49 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C7BA6827E; Thu, 17 Sep 2009 10:02:49 -0400 (EDT) In-Reply-To: (Glenn Morris's message of "Thu, 17 Sep 2009 03:32:35 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115413 Archived-At: >> - most importantly: it doesn't solve the problem at hand which is how >> to get rid of the other warning. > The other warning? >> - what's its use? It's not like we've seen lots of bugs where people >> use both defconst and defvar for a variable. > It simply replaces the current "variable assignment to a constant" > warning with a slightly more informative one, as you suggested. Sorry, I misread your patch. So you actually completely remove the defvar if var was already defconst'd. That's an attractive approach, tho it's a bit risky, because byte-compile-const-variables only contains variables that "may have been defconst'd", not those that "we know for sure have been defconst'd". E.g. try it with code such as (when toto (defconst foo bar)) (defvar foo nil) with your patch, you'd end up with `foo' undefined in the case where toto is nil. It may seem like a braindead case, but when comparing "broken code in corner cases" vs "incorrect warning in some cases", I prefer the incorrect warning. >> - Finally, if the defconst+defvar is really what you want to do (as in >> the present case where the defconst and the defvar both come from >> macros that we may not want to change), how do you silence >> the warning? > The same way you silence the current one about variable assignment to > a constant. :) The difference is that the current one is incorrect, so the act of silencing it needs to be done in bytecomp.el. Whereas yours is meant to be correct, in which case silencing it would need to be done by tweaking the code and/or using with-no-warnings (which I profoundly disklike). > I think it would be better to change define-derived-mode to not defvar > the map if it is already defined; I don't know how to do that. > or to change easy-mode-defmap to not use defconst That might be an acceptable workaround. But the underlying problem will still be there. > (are you saying users should not add key bindings to > log-edit-mode-map, for example?). That's unrelated: defconst only says that the variable's binding won't change, not that the object it is bound to is immutable. My locally hacked Emacs has "strong defconst" which really makes the variable immutable, so (setq log-edit-mode-map ) signals an error, but (define-key log-edit-mode-map [foo] 'bar) still works just fine. Stefan