From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: next-error-last-buffer Date: Sat, 29 May 2004 00:07:46 +0300 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87n03sfd1x.fsf@mail.jurta.org> References: <871xluig40.fsf@mail.jurta.org> <87u0y6jjq9.fsf@mail.jurta.org> <4nwu31j4ff.fsf@lifelogs.com> <87zn7wgtel.fsf@mail.jurta.org> <4nu0y0ef4z.fsf@lifelogs.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1085798861 16420 80.91.224.253 (29 May 2004 02:47:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 29 May 2004 02:47:41 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat May 29 04:47:33 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BTtsi-0001sh-00 for ; Sat, 29 May 2004 04:47:32 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BTtsi-0000NP-00 for ; Sat, 29 May 2004 04:47:32 +0200 Original-Received: from [127.0.0.1] (helo=mailman.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BTtsm-0003PP-Fh for emacs-devel@quimby.gnus.org; Fri, 28 May 2004 22:47:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BTtiu-0005hp-8q for emacs-devel@gnu.org; Fri, 28 May 2004 22:37:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BTtil-0005eE-P0 for emacs-devel@gnu.org; Fri, 28 May 2004 22:37:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BTtij-0005dn-HI for emacs-devel@gnu.org; Fri, 28 May 2004 22:37:13 -0400 Original-Received: from [66.33.219.6] (helo=knife.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BTpCh-0004mk-2H for emacs-devel@gnu.org; Fri, 28 May 2004 17:47:51 -0400 Original-Received: from mail.jurta.org (80-235-39-226-dsl.mus.estpak.ee [80.235.39.226]) by knife.dreamhost.com (Postfix) with ESMTP id 038AEE4067; Fri, 28 May 2004 14:47:47 -0700 (PDT) Original-To: Ted Zlatanov In-Reply-To: <4nu0y0ef4z.fsf@lifelogs.com> (Ted Zlatanov's message of "Fri, 28 May 2004 11:38:04 -0400") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 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:24115 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24115 Ted Zlatanov writes: > Let me make sure I understand the problem and solution. > > When next-error is called in buffer X, it may pop the user into > buffer Y. We want to unset next-error-function in Y, so that > next-error does not act in Y from that point on. Correct. > Couldn't this be achieved by making the next-error-last-buffer check > in next-error-find-buffer precede the current-buffer check? This change will solve the problem. > We need to define a function next-error-follow-this-buffer that would > set next-error-last-buffer to (current-buffer). That way, users can > force the behavior that now is the default, that next-error should act > on (current-buffer) first and foremost. I would bind > next-error-follow-this-buffer to C-x ~ (which on US keyboards is > Shift-` so remembering it is not too bad). There is no need for an additional function and keybinding. The action you proposed (i.e. setting next-error-last-buffer to (current-buffer)) could be performed in location-visiting functions usually bound to C-m and C-c C-c. But there is even simpler solution for the user to select a buffer for the next C-x `. Taking into account the recent addition of a rule in `next-error-find-buffer' which returns a buffer which is displayed only in one window with a next-error capable buffer on the selected frame, the user can simply remove the unwanted window with a next-error capable buffer (e.g. *grep* buffer in the aforementioned test case) from the selected frame and C-x ` will use the buffer from the remaining window (e.g. a patch file) even if it is not the same as next-error-last-buffer. So the only change needed is to modify the rule order like you proposed, which could look as below: 1. If one window on the selected frame displays such buffer, return it. 2. If next-error-last-buffer is set to a live buffer, use that. 3. If the current buffer is a next-error capable buffer, return it. ... -- Juri Linkov http://www.jurta.org/emacs/