From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: next-error use cases Date: Tue, 10 Apr 2018 23:06:25 +0300 Organization: LINKOV.NET Message-ID: <87y3huq3ta.fsf@mail.linkov.net> References: <87zi2esn7l.fsf@mail.linkov.net> <83in91zu5o.fsf@gnu.org> <834lkkzb9n.fsf@gnu.org> <878t9wp0oa.fsf@mail.linkov.net> <86604z3czx.fsf@stephe-leake.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1523391053 9417 195.159.176.226 (10 Apr 2018 20:10:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Apr 2018 20:10:53 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: emacs-devel To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 10 22:10:49 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f5zbN-0002MB-2s for ged-emacs-devel@m.gmane.org; Tue, 10 Apr 2018 22:10:49 +0200 Original-Received: from localhost ([::1]:42170 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f5zdS-0002oM-TH for ged-emacs-devel@m.gmane.org; Tue, 10 Apr 2018 16:12:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f5zdJ-0002mu-EM for emacs-devel@gnu.org; Tue, 10 Apr 2018 16:12:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f5zdF-00063J-FZ for emacs-devel@gnu.org; Tue, 10 Apr 2018 16:12:49 -0400 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:52262 helo=homiemail-a21.g.dreamhost.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f5zdF-00062f-97 for emacs-devel@gnu.org; Tue, 10 Apr 2018 16:12:45 -0400 Original-Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 18FEC1C0065; Tue, 10 Apr 2018 13:12:44 -0700 (PDT) Original-Received: from localhost.linkov.net (m91-129-105-236.cust.tele2.ee [91.129.105.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 3A6211C0062; Tue, 10 Apr 2018 13:12:43 -0700 (PDT) In-Reply-To: <86604z3czx.fsf@stephe-leake.org> (Stephen Leake's message of "Mon, 09 Apr 2018 23:24:18 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 69.163.253.7 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224502 Archived-At: >> Recently we created such command with the name =E2=80=98next-error-sel= ect-buffer=E2=80=99. >> Still too inconvenient for users to run this command explicitly. >> We need next-error to be more DWIM. > > That's what 'compilation-last-buffer' is for; it indicates the buffer > containing the location list that is current. I don't understand what do you mean by indication? Is it a visual indication somewhere? I grepped for 'compilation-last-buffer', but in compile.el 'compilation-last-buffer' is an alias for 'next-error-last-buf= fer', and grep.el contains commented out definition whose purpose I don't know: ;;;; TODO --- refine this!! ;; (defcustom grep-use-compilation-buffer t ;; "When non-nil, grep specific commands update `compilation-last-buf= fer'. ;; This means that standard compile commands like \\[next-error] and \\= [compile-goto-error] ;; can be used to navigate between grep matches (the default). ;; Otherwise, the grep specific commands like \\[grep-next-match] must ;; be used to navigate between grep matches." ;; :type 'boolean ;; :group 'grep) ;; override compilation-last-buffer (defvar grep-last-buffer nil "The most recent grep buffer. A grep buffer becomes most recent when you select Grep mode in it. Notice that using \\[next-error] or \\[compile-goto-error] modifies `compilation-last-buffer' rather than `grep-last-buffer'.") > As long as the user has a convenient way to set that, there's no > problem. In all my current use cases, it is first set by the command > that generated the location list. I can reset it by navigating to a > buffer, and using to goto a location; after that, 'next-error' > continues using that list. But how can you reset it when the location list is in the same buffer like in case of flyspell where locations of misspelled words are in the same buffer where next-error navigates, or flymake where locations of errors/warnings are in the same buffer?