From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: next-error use cases Date: Mon, 09 Apr 2018 23:24:18 -0500 Message-ID: <86604z3czx.fsf@stephe-leake.org> References: <87zi2esn7l.fsf@mail.linkov.net> <83in91zu5o.fsf@gnu.org> <834lkkzb9n.fsf@gnu.org> <878t9wp0oa.fsf@mail.linkov.net> 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 1523334149 22432 195.159.176.226 (10 Apr 2018 04:22:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Apr 2018 04:22:29 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 10 06:22:25 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 1f5knX-0005ic-EP for ged-emacs-devel@m.gmane.org; Tue, 10 Apr 2018 06:22:23 +0200 Original-Received: from localhost ([::1]:36818 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f5kpd-0003Bn-53 for ged-emacs-devel@m.gmane.org; Tue, 10 Apr 2018 00:24:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f5kpU-0003Aj-Cd for emacs-devel@gnu.org; Tue, 10 Apr 2018 00:24:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f5kpR-00013w-8k for emacs-devel@gnu.org; Tue, 10 Apr 2018 00:24:24 -0400 Original-Received: from smtp81.iad3b.emailsrvr.com ([146.20.161.81]:46487) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f5kpR-00013j-49 for emacs-devel@gnu.org; Tue, 10 Apr 2018 00:24:21 -0400 Original-Received: from smtp11.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp11.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id 7A8FF40061 for ; Tue, 10 Apr 2018 00:24:20 -0400 (EDT) X-Auth-ID: board-president@tomahawk-creek-hoa.com Original-Received: by smtp11.relay.iad3b.emailsrvr.com (Authenticated sender: board-president-AT-tomahawk-creek-hoa.com) with ESMTPSA id 470004005F for ; Tue, 10 Apr 2018 00:24:20 -0400 (EDT) X-Sender-Id: board-president@tomahawk-creek-hoa.com Original-Received: from Takver4 (76-218-37-33.lightspeed.kscymo.sbcglobal.net [76.218.37.33]) (using TLSv1.2 with cipher AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Tue, 10 Apr 2018 00:24:20 -0400 In-Reply-To: <878t9wp0oa.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 09 Apr 2018 23:47:17 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 146.20.161.81 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:224487 Archived-At: Juri Linkov writes: >>> > > Define some kind of priority between them? >>> > I really doubt we can define priorities such that the user will always >>> > want to see the errors of some "kind" before the others. >>> >>> Then maybe this problem has no workable solution at all, and we >>> shouldn't try running all those features from the same command. >> >> We could try, but in cases of doubt, ask the user what "next-error" >> function he wants to use (and provide some command for actively >> switching between them). For example, after calling "next-error" in >> some dubious case, the user could be offered a list of functions to >> choose between: >> >> - next Compile error from *compile* >> - next Occur result from *scratch* >> - next Grep result from *grep* >> ... > > Answering this after every next-error command would be too tedious for us= ers, > and it's not clear how to reduce the frequency of such questions, i.e. > how to detect only dubious cases. > >> There could also be other interfaces to pick a next-error function (a >> menu, or something like M-x list-buffers). > > Recently we created such command with the name =E2=80=98next-error-select= -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. 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. --=20 -- Stephe