From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.devel Subject: Re: Add M-x occur to the menu-bar Date: Tue, 02 Mar 2004 16:25:11 -0700 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <404517D7.7010808@yahoo.com> 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 1AyUlo-0000Gj-00 for ; Wed, 03 Mar 2004 12:42:36 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AyUln-00086J-00 for ; Wed, 03 Mar 2004 12:42:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1AyUlP-0006UT-36 for emacs-devel@quimby.gnus.org; Wed, 03 Mar 2004 06:42:11 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1AyJGp-0001f4-QM for emacs-devel@gnu.org; Tue, 02 Mar 2004 18:25:51 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1AyJGD-0001TB-3V for emacs-devel@gnu.org; Tue, 02 Mar 2004 18:25:45 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1AyJGC-0001Su-JU for emacs-devel@gnu.org; Tue, 02 Mar 2004 18:25:12 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AyJG8-0006FP-00 for ; Wed, 03 Mar 2004 00:25:08 +0100 Original-Received: from 170.207.51.80 ([170.207.51.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue Mar 2 23:25:08 2004 Original-Received: from ihs_4664 by 170.207.51.80 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue Mar 2 23:25:08 2004 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 40 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 170.207.51.80 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:0.9.4.1) Gecko/20020406 Netscape6/6.2.2 X-Accept-Language: en-us 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:20232 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20232 Richard Stallman wrote: > I follow the behavior of compile.el, which is: > > - is the current buffer usable? if yes, use it > > - else, if we were given a usable buffer, use that > > Could you say more precisely what "given" means, here? > Do you by any chance mean next-error-last-buffer? I sure hope so! > If so, what is the user-level behavior caused by this? Practically > speaking, if the user has done M-x compile and M-x occur, does this > get the compilation buffer or the occur buffer? What criteria > control this choice? > > - else, look through all the buffer for a usable buffer > > If there is more than one usable buffer, which one do you use? > Is it the compilation buffer, or the occur buffer? > > That is a very important question, for usability. The decision must > not be left to chance. It needs to be made intentionally, and we need > to verify users are happy with the decision. I think next-error should use the last created compile/grep/occur buffer, which is next-error-last-buffer because those commands reset its value. But I would like to give the user some control over that. For instance, if next-error-last-buffer were a list with the most recently created buffer at the front (like a stack), the user could go back to his/her previous next-error task simply by killing the most recent compile/grep/occur buffer. (Those buffers should remove themselves from the list when they're killed, so that next-error doesn't have to check for a dead buffer.) -- Kevin Rodgers