From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: next-error-find-buffer Date: Fri, 03 Aug 2007 21:19:50 +0300 Organization: JURTA Message-ID: <87y7gsqy49.fsf@jurta.org> References: <87r6mndorr.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1186165984 9951 80.91.229.12 (3 Aug 2007 18:33:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 3 Aug 2007 18:33:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 03 20:33:01 2007 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 1IH1xI-0008CH-H6 for ged-emacs-devel@m.gmane.org; Fri, 03 Aug 2007 20:32:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IH1x0-00010X-LL for ged-emacs-devel@m.gmane.org; Fri, 03 Aug 2007 14:32:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IH1wx-000102-1S for emacs-devel@gnu.org; Fri, 03 Aug 2007 14:32:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IH1wr-0000y1-Ai for emacs-devel@gnu.org; Fri, 03 Aug 2007 14:32:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IH1wr-0000xy-2N for emacs-devel@gnu.org; Fri, 03 Aug 2007 14:32:29 -0400 Original-Received: from barracuda.neti.ee ([194.126.101.113] helo=smtp-out.neti.ee) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IH1wa-0001O8-6k for emacs-devel@gnu.org; Fri, 03 Aug 2007 14:32:12 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by MXR-4.estpak.ee (Postfix) with ESMTP id 23D5F7D92; Fri, 3 Aug 2007 21:31:52 +0300 (EEST) X-Virus-Scanned: amavisd-new at !change-mydomain-variable!.example.com Original-Received: from smtp-out.neti.ee ([127.0.0.1]) by localhost (MXR-1.estpak.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5XcvwtQ4hNW; Fri, 3 Aug 2007 21:31:51 +0300 (EEST) Original-Received: from Relayhost3.neti.ee (relayhost3 [88.196.174.169]) by MXR-4.estpak.ee (Postfix) with ESMTP id 7A5D37CA2; Fri, 3 Aug 2007 21:31:51 +0300 (EEST) Original-Received: from mail.estpak.ee (84-50-157-21-dsl.est.estpak.ee [84.50.157.21]) by Relayhost3.neti.ee (Postfix) with ESMTP id D4B4198477; Fri, 3 Aug 2007 21:31:49 +0300 (EEST) In-Reply-To: (Stefan Monnier's message of "Thu\, 02 Aug 2007 12\:17\:44 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-Detected-Kernel: Linux 2.6 (newer, 3) 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:76004 Archived-At: > My original suggestion to fix number 2 was to introduce a new variable > next-error-last-source-buffer which is set to the last source buffer visited > by next-error. Then C-x ` would ignore current-buffer (and obey > next-error-last-buffer instead) if the current buffer is equal to > next-error-last-source-buffer: in the example problem, the C-x ` that puts > me in the patch file would set next-error-last-source-buffer to that patch > file buffer so hitting C-x ` in that patch file buffer would correctly > ignore the patch file buffer and use the compilation buffer instead. > > Any objection to the patch below? Perhaps a new variable next-error-last-source-buffer should be buffer-local. I imagine such a test case: C-x ` on a grep buffer visits the patch file, then in another frame on another grep buffer C-x ` visits its own patch file, then I switch back to the first patch file, type C-x `, and it will fail to visit the next grep hit from the first grep buffer, because the global next-error-last-source-buffer is set now to the second patch buffer from the second grep buffer. Please note that I concluded this outcome only by looking at your patch. I will try it for a few days to see how well it works in different cases. -- Juri Linkov http://www.jurta.org/emacs/