From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Add M-x occur to the menu-bar Date: 12 Feb 2004 15:57:25 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <3F69E6FF.9050702@yahoo.com> <4n8yjto16h.fsf@collins.bwh.harvard.edu> <4nisixjibl.fsf@collins.bwh.harvard.edu> <20040127230323.GB5407@fencepost> <4n7jzc919v.fsf@collins.bwh.harvard.edu> <4nn085i7nl.fsf@collins.bwh.harvard.edu> <4noese37h0.fsf@collins.bwh.harvard.edu> <4nbrodxwqm.fsf@collins.bwh.harvard.edu> <4n8yjcccvj.fsf@collins.bwh.harvard.edu> <4nwu6sp7ni.fsf@collins.bwh.harvard.edu> Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ArgHd-00051V-00 for ; Fri, 13 Feb 2004 17:35:17 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ArgHd-0006bG-00 for ; Fri, 13 Feb 2004 17:35:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ArgEL-0007FR-Tz for emacs-devel@quimby.gnus.org; Fri, 13 Feb 2004 11:31:53 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ArgE0-0007CO-Uy for emacs-devel@gnu.org; Fri, 13 Feb 2004 11:31:32 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ArgDO-0006qz-Sc for emacs-devel@gnu.org; Fri, 13 Feb 2004 11:31:26 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1ArgDN-0006py-Nn for emacs-devel@gnu.org; Fri, 13 Feb 2004 11:30:53 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by mx20.gnu.org with esmtp (Exim 4.24) id 1Arg3K-00031o-5q for emacs-devel@gnu.org; Fri, 13 Feb 2004 11:20:30 -0500 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id B633820FC2; Thu, 12 Feb 2004 15:57:25 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 7D07D8C70D; Thu, 12 Feb 2004 15:57:25 -0500 (EST) Original-To: Ted Zlatanov In-Reply-To: <4nr7x0ox3l.fsf@collins.bwh.harvard.edu> Original-Lines: 56 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, BAYES_00 -4.90) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19916 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19916 > I think Kim suggested that. It's so that multiple modes can set > compilation-next-error-function without using make-local-variable. If > you change it, you're just pushing that work to the modes that use > this interface. I think it's 6 one way, half-dozen the other, so > whatever the Emacs developers prefer is fine with me. I think the general feling I got over the years is that make-local-variable should generally be preferred over make-variable-buffer-local. For exemple the elisp manual says: The time to use `make-variable-buffer-local' is when it is crucial that no two buffers ever share the same binding. For example, when a variable is used for internal purposes in a Lisp program which depends on having separate values in separate buffers, then using `make-variable-buffer-local' can be the best solution. One of the classic pitfalls of make-variable-buffer-local which your code suffers from is the following: Say I change diff-mode to do (setq compilation-next-error-function 'diff-foo) just like I intend to. Now the behavior will be either to set the local or the global vriable depending on whether or not compile.el has already been loaded. And no: requiring compile.el is not an acceptable option. >> Also why not rename next-error to compilation-next-error, then >> default compilation-next-error-function to compilation-next-error >> and just write: >> >> (defun next-error (argp) >> (interactive ...) >> (with-current-buffer compilation-last-buffer >> (funcall compilation-next-error-function argp)) > compilation-last-buffer is not necessarily what we want. We need to > find a suitable buffer, so you can run next-error anywhere and at any > time. That preserves the existing semantics of next-error; I don't > think your version does. I may be wrong, though. My code was not intended to be taken as is, obviously. I just wanted to say is that instead of (defvar X-function nil) ... ..(if X-function (funcall X-function) (do-something)) you can do (defvar X-function 'X-default) (defun X-default () (do-something)) ... ..(funcall X-function) -- Stefan