From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 00:31:22 2014 Received: (at submit) by debbugs.gnu.org; 3 May 2014 04:31:23 +0000 Received: from localhost ([127.0.0.1]:49006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WgRbe-00015B-Ce for submit@debbugs.gnu.org; Sat, 03 May 2014 00:31:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38959) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WgRbb-00014p-5i for submit@debbugs.gnu.org; Sat, 03 May 2014 00:31:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WgRbL-0004A0-I0 for submit@debbugs.gnu.org; Sat, 03 May 2014 00:31:14 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:45843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgRbL-00049w-F8 for submit@debbugs.gnu.org; Sat, 03 May 2014 00:31:03 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40644) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgRbC-0004pB-MU for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 00:31:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WgRb3-0003oA-Vj for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 00:30:54 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:25918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgRb3-0003o4-P4 for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 00:30:45 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s434UhxE008023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 3 May 2014 04:30:44 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s434Uh2w029227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 3 May 2014 04:30:43 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s434UgS7009873 for ; Sat, 3 May 2014 04:30:42 GMT MIME-Version: 1.0 Message-ID: <1257238c-02c2-48f6-a4f1-c53674f87734@default> Date: Fri, 2 May 2014 21:30:41 -0700 (PDT) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 24.4.50; enhancement request: split `next-error-function' functionality in two X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) Enhancement request, to make the `next-error' feature, or more precisely the buffers that offer it, more usable by other Lisp functions. Currently, buffers, such as `occur' and `grep', that provide `next-error' information hold the destination information for each hit in different ways, and they provide a function for the buffer-local value of `next-error-function' that does two things together: 1. Get the destination information for the next (or previous) hit, e.g. based on point in the search-hits buffer. 2. Go to that search-hit destination. What I would like to see is a buffer-local variable whose value is a function that does only #1. (This var would then be used by a function that is the value of `next-error function', to do its #1 part.) Why? Because instead of just going to the "next" or "previous" hit, I want to gather all of the hits at once, to serve as candidates (e.g. completion candidates) for another way of choosing and navigating among them (e.g. in different orders besides "next" in the hit list). (I sometimes want to in fact visit the target buffers during a #1 function call and pick up some text at or near the hit position to serve as the candidate text, if what is in the error buffer does not provide the best context for choosing. But all I'm really asking for here is to get the search-hit destinations (locations).) This is easy enough to do for each particular buffer and mode such as occur or grep separately, but each one is different. The point of variable `next-error-function' is to provide a common interface: just call the value of that function to do #1 and #2 - no need to know how the given search-hit buffer represents/maps the hit information. When I call the function (the value of the new variable) to do #1, I just want it to return the information for the next hit (its location). I do not want to actually visit the hit at that time for the user, displaying and raising the destination buffer etc. I want to gather the destination information for each of the hits, and in a buffer/mode-independent way. Essentially, I want a wrapper that provides a common interface to the hit information that is stored in the different error buffers in different ways. AFAICT, there is no such feature today, but let me know if I'm missing something obvious. And let me know if this request is not clear to you. In GNU Emacs 24.4.50.1 (i686-pc-mingw32) of 2014-04-29 on ODIEONE Bzr revision: 117031 monnier@iro.umontreal.ca-20140429151607-qnkgbymwfaj5ut= 08 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=3D/c/Devel/emacs/snapshot/trunk --enable-checking=3Dyes,glyphs 'CFLAGS=3D-O0 -g3' LDFLAGS=3D-Lc:/Devel/emacs/lib 'CPPFLAGS=3D-DGC_MCHECK=3D1 -Ic:/Devel/emacs/include'' From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 17:38:53 2014 Received: (at 17394) by debbugs.gnu.org; 3 May 2014 21:38:53 +0000 Received: from localhost ([127.0.0.1]:50031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wghe1-0005nu-3o for submit@debbugs.gnu.org; Sat, 03 May 2014 17:38:53 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:25598) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wghdz-0005na-20 for 17394@debbugs.gnu.org; Sat, 03 May 2014 17:38:51 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s43Lci9b030476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <17394@debbugs.gnu.org>; Sat, 3 May 2014 21:38:45 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s43Lchx5013991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <17394@debbugs.gnu.org>; Sat, 3 May 2014 21:38:44 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s43LchAm019402 for <17394@debbugs.gnu.org>; Sat, 3 May 2014 21:38:43 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 3 May 2014 14:38:43 -0700 (PDT) From: Drew Adams To: 17394@debbugs.gnu.org Subject: RE: bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two References: <1257238c-02c2-48f6-a4f1-c53674f87734@default> In-Reply-To: <1257238c-02c2-48f6-a4f1-c53674f87734@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17394 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) Needless to say, this bug is present also in the 24.4 pretest. (I am using this development version at Stefan's request, to try to catch the crash of bug #17340 with his patch.) From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 17:41:58 2014 Received: (at 17394) by debbugs.gnu.org; 3 May 2014 21:41:58 +0000 Received: from localhost ([127.0.0.1]:50041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wghh0-0005u4-AM for submit@debbugs.gnu.org; Sat, 03 May 2014 17:41:58 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:46281) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wghgx-0005to-CV for 17394@debbugs.gnu.org; Sat, 03 May 2014 17:41:56 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s43LfnMW031926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <17394@debbugs.gnu.org>; Sat, 3 May 2014 21:41:49 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s43Lfm2W018060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <17394@debbugs.gnu.org>; Sat, 3 May 2014 21:41:48 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s43LfmtR004811 for <17394@debbugs.gnu.org>; Sat, 3 May 2014 21:41:48 GMT MIME-Version: 1.0 Message-ID: <8e5b87a9-8382-4d9e-887f-5d36f07df917@default> Date: Sat, 3 May 2014 14:41:48 -0700 (PDT) From: Drew Adams To: 17394@debbugs.gnu.org Subject: RE: bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two References: <1257238c-02c2-48f6-a4f1-c53674f87734@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17394 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > Needless to say, this bug is present also in the 24.4 pretest. Sorry, that was meant for #17397, not #17394. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 05 10:27:57 2014 Received: (at submit) by debbugs.gnu.org; 5 Jun 2014 14:27:57 +0000 Received: from localhost ([127.0.0.1]:45823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WsYe0-0006yJ-S8 for submit@debbugs.gnu.org; Thu, 05 Jun 2014 10:27:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51515) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WsYdv-0006xx-F3 for submit@debbugs.gnu.org; Thu, 05 Jun 2014 10:27:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsYdj-0002Io-V2 for submit@debbugs.gnu.org; Thu, 05 Jun 2014 10:27:42 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:46970) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsYdj-0002Ik-Si for submit@debbugs.gnu.org; Thu, 05 Jun 2014 10:27:35 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsYdd-0006A7-L7 for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 10:27:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsYdX-0002Ch-Bo for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 10:27:29 -0400 Received: from plane.gmane.org ([80.91.229.3]:57004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsYdX-0002Bm-5W for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 10:27:23 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WsYdP-0005OV-Fz for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 16:27:15 +0200 Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Jun 2014 16:27:15 +0200 Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Jun 2014 16:27:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: bug-gnu-emacs@gnu.org To: bug-gnu-emacs@gnu.org From: Ted Zlatanov Subject: Re: bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two Date: Thu, 05 Jun 2014 10:27:06 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Lines: 18 Message-ID: <87y4xbfn45.fsf@lifelogs.com> References: <1257238c-02c2-48f6-a4f1-c53674f87734@default> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:E71rbQCaGYaPVQ3DrpKJBChsuBs= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bug-gnu-emacs@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) On Fri, 2 May 2014 21:30:41 -0700 (PDT) Drew Adams wrote: DA> Enhancement request, to make the `next-error' feature, or more precisely DA> the buffers that offer it, more usable by other Lisp functions. ... DA> Essentially, I want a wrapper that provides a common interface to the DA> hit information that is stored in the different error buffers in DA> different ways. AFAICT, there is no such feature today, but let me know DA> if I'm missing something obvious. And let me know if this request is DA> not clear to you. This may work for some modes but not others. The `next-error' facility is opaque to the caller because each mode has to decide what makes sense in terms of locations and motion to them. So I think trying to expose more of the internals and formalize them would limit the ways in which it can be useful. Ted From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 05 14:15:46 2014 Received: (at submit) by debbugs.gnu.org; 5 Jun 2014 18:15:46 +0000 Received: from localhost ([127.0.0.1]:46085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WscCT-0007mL-ON for submit@debbugs.gnu.org; Thu, 05 Jun 2014 14:15:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52767) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WscCN-0007lu-Re for submit@debbugs.gnu.org; Thu, 05 Jun 2014 14:15:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WscC9-0005LF-TP for submit@debbugs.gnu.org; Thu, 05 Jun 2014 14:15:30 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:60142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WscC9-0005LA-RW for submit@debbugs.gnu.org; Thu, 05 Jun 2014 14:15:21 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WscC1-0007Yp-O9 for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 14:15:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WscBt-0005AL-Hf for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 14:15:13 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:45861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WscBt-000597-Ap for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 14:15:05 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s55IEsGr025231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jun 2014 18:14:54 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s55IEqaS018067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Jun 2014 18:14:54 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s55IEqvn013820; Thu, 5 Jun 2014 18:14:52 GMT MIME-Version: 1.0 Message-ID: Date: Thu, 5 Jun 2014 11:14:51 -0700 (PDT) From: Drew Adams To: bug-gnu-emacs@gnu.org, 17394@debbugs.gnu.org Subject: RE: bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two References: <1257238c-02c2-48f6-a4f1-c53674f87734@default> <87y4xbfn45.fsf@lifelogs.com> In-Reply-To: <87y4xbfn45.fsf@lifelogs.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) > DA> Enhancement request, to make the `next-error' feature, or more precis= ely > DA> the buffers that offer it, more usable by other Lisp functions. > ... > DA> Essentially, I want a wrapper that provides a common interface to the > DA> hit information that is stored in the different error buffers in > DA> different ways. AFAICT, there is no such feature today, but let me k= now > DA> if I'm missing something obvious. And let me know if this request is > DA> not clear to you. >=20 > This may work for some modes but not others. The `next-error' facility > is opaque to the caller because each mode has to decide what makes sense > in terms of locations and motion to them. So I think trying to expose > more of the internals and formalize them would limit the ways in which > it can be useful. I don't understand at least two things in what you wrote, Ted: * Why mode-specific determination of locations etc. is relevant to the request. * Why the request would require exposing any internals. I want to have access to the go-to-target info in whatever buffer/mode, whether it is a function or a location (e.g. buffer + marker) or whatever, as data (e.g. an alist entry). You can use `next-error' from anywhere. I want to be able to gather all `next-error' target locations and use them as completion candidates. For that, I want, for example, an alist entry that includes the necessary info: the target buffer and location (or location-finding function). When I say "data", I mean just some Lisp entity that I can use to get to the location in the given buffer (on demand, i.e., when the user chooses a completion candidate). It could be a function - it need not be a passive data structure. I do not want to *visit* all of the candidate locations just in order to gather that info. That's the point. Here is one use of such a feature: http://stackoverflow.com/questions/21125015/cycle-through-results-using-nex= t-error-previous-error In my case, I would provide an Icicles search multi-command that would let you browse the `next-error' target candidates, narrowing to subsets of them, jumping among them (i.e., visiting them) in any order, etc. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 05 17:25:50 2014 Received: (at 17394) by debbugs.gnu.org; 5 Jun 2014 21:25:50 +0000 Received: from localhost ([127.0.0.1]:46166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WsfAT-0005t2-9P for submit@debbugs.gnu.org; Thu, 05 Jun 2014 17:25:49 -0400 Received: from mail-qa0-f52.google.com ([209.85.216.52]:39784) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WsfAQ-0005sl-Ib for 17394@debbugs.gnu.org; Thu, 05 Jun 2014 17:25:47 -0400 Received: by mail-qa0-f52.google.com with SMTP id cm18so2252465qab.39 for <17394@debbugs.gnu.org>; Thu, 05 Jun 2014 14:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifelogs.com; s=google; h=from:to:cc:subject:organization:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=7tTICiWpaZetfCmOVj5w1GxDP2ALEBHo6m7JfEbBN7k=; b=UBj86IjmZVSmawbR7vtHWpgXrPdn0Tl7nNQBAGz1CLoubEulv685LwBfxj/99xicNJ 3T8TGxQ6VJdfPASJcwIhTTQ/f5DX10JZNLC3zOCxqTKI+f21VA0EeXRtXCZLb709uAIc kG7YB4LX4lg26xK7ssVpXKu4mBK4ZddAjGw4A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:organization:references :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=7tTICiWpaZetfCmOVj5w1GxDP2ALEBHo6m7JfEbBN7k=; b=eGH/5fZzaid7XqBDOYsFk05eHlYAKJ+ysq3lWgvX1onNZqPuhWItimslaWAkaVHnbc 5zqUhp91pOrqGhxpPO+efr0U8GNVk8fAIqRDBfJIJOhtHuOFbVHu6Wdm5l8Digc9zk+b W53roHd/r8grpthZtOD19CKFE7EbE+qTs4f+VK3fpS5BBrsUqupmYC3S+NkA+4+3Qo7R PY5LOMa2NQTnT8hGk3sCXbDNci769LNMzIjn2Mb3gmb2wnPpyKhNZJ0fDykh6BmwHzx4 x9xoLKbME/lAR5o1VaFVuDTMB64kAjN+JBN734wXeBLKJdTL5Y0iI+UOrVbx3xjWtwdB IlxQ== X-Gm-Message-State: ALoCoQlmxbKeZ0/qTQGDqGV9r3SYPRjRMby/cKjC+SYYpc2mo+dD6ENxYBYU4uPxPNCpkE5Hf2XC X-Received: by 10.224.8.131 with SMTP id h3mr373316qah.61.1402003540954; Thu, 05 Jun 2014 14:25:40 -0700 (PDT) Received: from flea (c-98-229-61-72.hsd1.ma.comcast.net. [98.229.61.72]) by mx.google.com with ESMTPSA id e12sm11315933qaq.13.2014.06.05.14.25.39 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 05 Jun 2014 14:25:40 -0700 (PDT) From: Ted Zlatanov To: Drew Adams Subject: Re: bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos References: <1257238c-02c2-48f6-a4f1-c53674f87734@default> <87y4xbfn45.fsf@lifelogs.com> X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Thu, 05 Jun 2014 17:25:42 -0400 In-Reply-To: (Drew Adams's message of "Thu, 5 Jun 2014 11:14:51 -0700 (PDT)") Message-ID: <87mwdrf3qh.fsf@lifelogs.com> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17394 Cc: 17394@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Thu, 5 Jun 2014 11:14:51 -0700 (PDT) Drew Adams wrote: DA> Enhancement request, to make the `next-error' feature, or more precisely DA> the buffers that offer it, more usable by other Lisp functions. >> ... DA> Essentially, I want a wrapper that provides a common interface to the DA> hit information that is stored in the different error buffers in DA> different ways. AFAICT, there is no such feature today, but let me know DA> if I'm missing something obvious. And let me know if this request is DA> not clear to you. >> >> This may work for some modes but not others. The `next-error' facility >> is opaque to the caller because each mode has to decide what makes sense >> in terms of locations and motion to them. So I think trying to expose >> more of the internals and formalize them would limit the ways in which >> it can be useful. DA> I don't understand at least two things in what you wrote, Ted: DA> * Why mode-specific determination of locations etc. is relevant to the DA> request. ... DA> You can use `next-error' from anywhere. I want to be able to gather all DA> `next-error' target locations and use them as completion candidates. That's the request, as you said yourself shortly thereafter and I quoted :) DA> * Why the request would require exposing any internals. Because breaking `next-error-function' into two pieces (list locations and move to them) as you suggest requires each mode to expose what it considers "locations" to you and stick to that contract when the locations are visited externally. It also dictates that calling `next-error' means to move to a location, whereas modes and users currently are free to do other things when `next-error' is called. It's just my opinion, so I hope others have feedback for you as well. Ted From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 05 17:52:41 2014 Received: (at 17394) by debbugs.gnu.org; 5 Jun 2014 21:52:41 +0000 Received: from localhost ([127.0.0.1]:46180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WsfaS-0006oU-AD for submit@debbugs.gnu.org; Thu, 05 Jun 2014 17:52:40 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:35697) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WsfaP-0006oC-0x for 17394@debbugs.gnu.org; Thu, 05 Jun 2014 17:52:37 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s55LqTer000988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jun 2014 21:52:30 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s55LqS1e012257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2014 21:52:29 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s55LqSCK012252; Thu, 5 Jun 2014 21:52:28 GMT MIME-Version: 1.0 Message-ID: <5f61d1ec-4647-4171-bfac-6dd780023695@default> Date: Thu, 5 Jun 2014 14:52:27 -0700 (PDT) From: Drew Adams To: Ted Zlatanov Subject: RE: bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two References: <1257238c-02c2-48f6-a4f1-c53674f87734@default> <87y4xbfn45.fsf@lifelogs.com> <87mwdrf3qh.fsf@lifelogs.com> In-Reply-To: <87mwdrf3qh.fsf@lifelogs.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17394 Cc: 17394@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > DA> Enhancement request, to make the `next-error' feature, or more precis= ely > DA> the buffers that offer it, more usable by other Lisp functions. > >> ... > DA> Essentially, I want a wrapper that provides a common interface to the > DA> hit information that is stored in the different error buffers in > DA> different ways. AFAICT, there is no such feature today, but let me k= now > DA> if I'm missing something obvious. And let me know if this request is > DA> not clear to you. > >> > >> This may work for some modes but not others. The `next-error' facility > >> is opaque to the caller because each mode has to decide what makes sen= se > >> in terms of locations and motion to them. So I think trying to expose > >> more of the internals and formalize them would limit the ways in which > >> it can be useful. >=20 > DA> I don't understand at least two things in what you wrote, Ted: >=20 > DA> * Why mode-specific determination of locations etc. is relevant to th= e > DA> request. > ... > DA> You can use `next-error' from anywhere. I want to be able to gather = all > DA> `next-error' target locations and use them as completion candidates. >=20 > That's the request, as you said yourself shortly thereafter and I quoted = :) Sorry, I don't understand your reply. > DA> * Why the request would require exposing any internals. >=20 > Because breaking `next-error-function' into two pieces (list locations > and move to them) as you suggest requires each mode to expose what it > considers "locations" to you and stick to that contract when the > locations are visited externally. See below, wrt bookmarks. (Or think Emacs file handlers.) There is nothing particularly constraining about providing a Lisp representation of (getting to) a potential target (destination/location). > It also dictates that calling `next-error' means to move to a location, > whereas modes and users currently are free to do other things when > `next-error' is called. I agree that "location" can mean pretty much anything - just as it does, for example, for "jumping" to a bookmark "location". That does not stop bookmarks from recording such destinations - either extensively/explicitly, as traditional locations, or intensively/implicitly, as handler functions. An Emacs bookmark can do anything at all. It needs only (a) a name and (b) info sufficient to allow carrying out the intended effect. Nothing in what I suggested requires `next-error' to in fact literally "move to a location". The requirement is for a representation of the effect (whether we call it "location" or something else). A representation that provides" (a) a user-recognizable component (name/label - something you can recognize and choose) and (b) the associated effect: something that can be used by Lisp code to bring about the effect. For an explicit location, (b) might be a buffer or file and a position in it (a number or marker), and (a) might be some text at or near that location. But the request in no way imposes this as a limitation. Again, think bookmarks. [A bookmark, whose the data is recorded persistently, can be used long after it was defined and in a context that has changed since. Even so, Emacs can typically find the location. This should be even less of a problem (and typically not a problem at all, I expect) for `next-error' "locations".] From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 25 09:29:14 2022 Received: (at submit) by debbugs.gnu.org; 25 Jan 2022 14:29:15 +0000 Received: from localhost ([127.0.0.1]:47625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCMos-0000iU-Bp for submit@debbugs.gnu.org; Tue, 25 Jan 2022 09:29:14 -0500 Received: from lists.gnu.org ([209.51.188.17]:37376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCMop-0000iK-QD for submit@debbugs.gnu.org; Tue, 25 Jan 2022 09:29:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCMoo-0004Rl-Q3 for bug-gnu-emacs@gnu.org; Tue, 25 Jan 2022 09:29:11 -0500 Received: from [2a01:4f9:2b:f0f::2] (port=53684 helo=quimby.gnus.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCMol-0007Lq-SD for bug-gnu-emacs@gnu.org; Tue, 25 Jan 2022 09:29:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=JiNDvWS1407fmqwtbmHqBsYLXzztqV5eVzkqrlJaPD4=; b=FK8rLIO0PZ+fmrSE0I1JMf8LWy 4o/Y9RWuyok3L01QK+r7v9Y2NmhXBR7BtnNVUVVse7Xi/nFyUqhFz+du5y9rNSl09/36ji69xkFHs qb84nsj4OW/gyDGDajFRZ2XDAO7K+OaYFa+pjIt3hy5J2tT3VqMAjGFeuRMwTB7I176Y=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nCMoW-0004qJ-EH for bug-gnu-emacs@gnu.org; Tue, 25 Jan 2022 15:28:55 +0100 From: Lars Ingebrigtsen To: bug-gnu-emacs@gnu.org Subject: Re: bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two References: <1257238c-02c2-48f6-a4f1-c53674f87734@default> <87y4xbfn45.fsf@lifelogs.com> X-Now-Playing: David Bowie's _Brilliant Adventure (11): Re:Call 5_: "Seven (demo)" Date: Tue, 25 Jan 2022 15:28:48 +0100 In-Reply-To: <87y4xbfn45.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu, 05 Jun 2014 10:27:06 -0400") Message-ID: <87sftbvqhr.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Ted Zlatanov writes: > This may work for some modes but not others. The `next-error' facility > is opaque to the caller because each mode has to decide what makes sense > in terms of locations and motion to them. So I thi [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a01:4f9:2b:f0f::2 (failed) Received-SPF: pass client-ip=2a01:4f9:2b:f0f::2; envelope-from=larsi@gnus.org; helo=quimby.gnus.org X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Ted Zlatanov writes: > This may work for some modes but not others. The `next-error' facility > is opaque to the caller because each mode has to decide what makes sense > in terms of locations and motion to them. So I think trying to expose > more of the internals and formalize them would limit the ways in which > it can be useful. Skimming this thread, I agree, so I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 25 09:29:10 2022 Received: (at control) by debbugs.gnu.org; 25 Jan 2022 14:29:10 +0000 Received: from localhost ([127.0.0.1]:47622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCMoo-0000iB-62 for submit@debbugs.gnu.org; Tue, 25 Jan 2022 09:29:10 -0500 Received: from quimby.gnus.org ([95.216.78.240]:35786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCMom-0000hx-5b for control@debbugs.gnu.org; Tue, 25 Jan 2022 09:29:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jiKPhAatxT9TRBPRbjcwOyHSG7ZGT9swtofG4jpWJy8=; b=oROjkgfD1iZhbfN00Jq6wUyIuH FPd/q7yAV0S7yIovfQx7nN57w7mAXrfJVXQuAvmfJ70nfLuM/ZtGcaAIXXeXB+NAsOBPk8s0KoXcN d7FUIfuWgZYtK3gzf5hQBxf9CLwHJzLO5BF2Rs4JJkhopC1ym+h1TL36RnTmLGFdBwSc=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nCMod-0004qU-Lz for control@debbugs.gnu.org; Tue, 25 Jan 2022 15:29:01 +0100 Date: Tue, 25 Jan 2022 15:28:58 +0100 Message-Id: <87r18vvqhh.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #17394 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 17394 wontfix close 17394 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 17394 wontfix close 17394 quit From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 25 11:17:43 2022 Received: (at 17394) by debbugs.gnu.org; 25 Jan 2022 16:17:43 +0000 Received: from localhost ([127.0.0.1]:49878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCOVq-0000CX-NB for submit@debbugs.gnu.org; Tue, 25 Jan 2022 11:17:43 -0500 Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:12186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCOVl-0000CM-RT for 17394@debbugs.gnu.org; Tue, 25 Jan 2022 11:17:41 -0500 Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 20PG50SV029546; Tue, 25 Jan 2022 16:17:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2021-07-09; bh=c/8u60PtQJxcVNnwe4uNJMEBJZsBnbRBwBIaqHXHGoM=; b=JtDjf9ic3HCuLZSjCOD5n1BtBFTMhY5+x4e1wz03a4WwKjq3pCu1xcBgJEI1HiN0BH9+ y+bAxIEcCNIvsstOP/Lq2XT7PEmRkLa61ctKhrT/bHQktk947F5qXGBns1rmV6K8e07O 4pu2L6FGfM6/+YIkg64jrYyY4A2GSCMcGaJCDtmlk5iiy8WRDhIYxLNok5RF2W0m4M6X /F6guST+/cKPGghwBB/59IdETAwVZ/lUwE+C38It0A81k7hKeQ4VLqKv+tja2njX1KbN xQoqNfDHC+w6RxPOw6WPPYO2XD0eAdwHe1APXzl8v389bDjCyI9GDzQn52xwb+wEYyR0 +g== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by mx0b-00069f02.pphosted.com with ESMTP id 3dsy7aujw3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Jan 2022 16:17:35 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 20PGAl0T117467; Tue, 25 Jan 2022 16:17:34 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam08lp2044.outbound.protection.outlook.com [104.47.73.44]) by aserp3020.oracle.com with ESMTP id 3dtax6t0r6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Jan 2022 16:17:34 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XqAsr1nQx1b+SQYr3rHEMPvx22RoOgoXEaHGfuqP0JCtUxKm9Ymq/RCGLjCf5L1jWAyWgEAe3GKn/VydL7DOlKxuP2pGor2FBq+NsWGHNjY743mLf49x2IgVGNl2i25bvMMUNcTzuqLtpoHrsLHJyDCH+8pFGsTxAVqdoIMMshoNzrD9rtHYCjcy/7YKCqrQQVSjVUDB7JI8vT42FpHIf5DkyLvkm4XvcC3xKV8CF9fUJwFfek8K3Df3QEFBcDPXK/bpdaYdcR2cZgRgy5TGCVPd8YCCV+s2mle/JPh5ekbBr3zL1lvk0TuLBEjqjCKjHmsMncdKgrCFFw2bUphOGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=c/8u60PtQJxcVNnwe4uNJMEBJZsBnbRBwBIaqHXHGoM=; b=lenHx4HhLeEinkwLjcNOcBi6B50O73QAoI9VGcV0la1IK8Kw6ghWgpqFgEWxkuHnDB02LuzTQgFxe2gsaVRsajs8KS/0rf3Fyx499bpzgminExfair4ehqxVypK9Rkdt5NoG3M0kyYPXEg3NJYrKzFW/xTJ5rP9WzZjbuTs808vCL/QK0dRhlBZuVgd/Tk7QQ0d8tz0VoCJrNC++N9/z8u1tTjrhD0P+bo4EmLNs6cQx36IXRaU5fE0k4nu6rpF38RiSqN5Fz3gpK4bRK7QOAeNSa2S0J00L2bfL753X3FCvYVd1Zt+wt+h1OQjG1Y/WqAPAuwjL0XFQ/W8345NKxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c/8u60PtQJxcVNnwe4uNJMEBJZsBnbRBwBIaqHXHGoM=; b=iijSw45ehROSSytu17HybPeDFXbBuV0ddxUIlr1hpd738adXGSSbljfMjCNpoNjmi0a7NEP4R2rhbdpOmqUXoe9T91rzoGXGTNUsuJvX5ijJg5bngNdlZOYuzePg9vsbwtD0IzEbjW7F+xaKxhCBM97aKKIFmk7XPzRr5Ad50ho= Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by BN6PR10MB1987.namprd10.prod.outlook.com (2603:10b6:404:103::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.15; Tue, 25 Jan 2022 16:17:31 +0000 Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::99a4:696f:5f30:36b3]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::99a4:696f:5f30:36b3%6]) with mapi id 15.20.4930.015; Tue, 25 Jan 2022 16:17:31 +0000 From: Drew Adams To: Lars Ingebrigtsen , "17394@debbugs.gnu.org" <17394@debbugs.gnu.org> Subject: RE: [External] : bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two Thread-Topic: [External] : bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two Thread-Index: AQHYEf/4RavUyWhW9kmXQkdJOChw1axz6CUg Date: Tue, 25 Jan 2022 16:17:31 +0000 Message-ID: References: <1257238c-02c2-48f6-a4f1-c53674f87734@default> <87y4xbfn45.fsf@lifelogs.com> <87sftbvqhr.fsf@gnus.org> In-Reply-To: <87sftbvqhr.fsf@gnus.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f5fba36-4881-49a7-eefb-08d9e01e3095 x-ms-traffictypediagnostic: BN6PR10MB1987:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xSJvX37paT7y2M1jHMm/WUsXlIHFfuuOED4MsmVxVtddvXQwvvlSyvpOs9iiqRCV10A+V883Dp3GNtA+UcSvy/JsQXkFd4MI3XD0ZepgWu9080QglQyNXgwT14mkOyiyvpmq5ltnFGYPWM6puJ607Ro1qsp+J2qMm6dK3KvBg0H0cuNhgCMLGeRbBVs1zyZyu7zwWTl2c9+p1+lVBbo00v+EwJKWltlUWRffgFm+yCURTEJcFDpQLLdCYHxtJwuEIi38zfsUtGqOLyOqAwa6ACVgKM5iAzUu28BIRBhPgLm3+myJXGTJ8uqynZQ4cII2F3UMDEThSy1kPnxCMXOJyrqOBtqWHeCkDodkyaEaHhWaO2UHN5pjyvG8dVJ0kZiIKefNfpi4fmY73D2UGnmsqsrQdoJ1wFHHVQoesQnt0sidnmdtIHd0NP85KZpliGTXpodl+Bb6uHgjEmk/74Y8lW1x5ieqgaxY/WEMqP4qUcYwPg+ZQc8bb4jZY4gWIutXtQWluAzJhti2CKLocPn07YB3RQfns/h8mNd8Yp88hkIbBXNrrnWdjaoHyQ5CmX+jAQNC55Y2WGkELmGBPGbeLrrkmYldqCPfhNiyPKTAezSDwGxdB1ObSd5TKHLpqH9B7nAkCRZfqTa/r95dBShStCGtnRfOxsIUo0Pgwm2RdvsgJGtSjsd+JrGKXy+vZ7sF7EXrrTJy98+o0WNYn7QuPJF7uQo6mUAPo9wLB3cptLM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(86362001)(83380400001)(8676002)(8936002)(4744005)(38070700005)(122000001)(38100700002)(5660300002)(64756008)(66446008)(110136005)(2906002)(508600001)(44832011)(33656002)(9686003)(7696005)(6506007)(52536014)(55016003)(316002)(26005)(76116006)(71200400001)(186003)(66556008)(66946007)(66476007)(81973001)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?1SyEVrdPEplw/pXmeCghnA2V9d2+8pP4iau7Yuae2A3I+swMZFVdTIt+VX/O?= =?us-ascii?Q?lqhbjHYmxGzCnexdJxfshwDtgdqyqci42caP3vZDGxHsWbzaFyes1FxCb0gD?= =?us-ascii?Q?nWyyQ97wV7Xj0uiCx8wSWXB8ycYhpgH1En2Ja8gESiiCaa/ULOHvkKyW72wv?= =?us-ascii?Q?pInDEBEuZAfwfnG4upxGCqDoKzhs9l2aW3O9zib+GWmNNntKe9eqi6r5bqk6?= =?us-ascii?Q?lG1XksxjXzXcbir3uydWvqGXBSpxsNZPxVcEueww0aPah7FOTLGJvF2v7KC/?= =?us-ascii?Q?SSPqPN5OTrptg/s6VzQ7sSI7MA6QndWrPa+y/tBkgK5Q7+x8TtFqXxxrlb7E?= =?us-ascii?Q?cv8zfkKk8fwkVxOOJTVHyjf4Pr/7wI5/NHwdh7jlfHsgkQrPupPMr1qLPvMc?= =?us-ascii?Q?cSAxgzzXDQlhRd3nRCZTAxEjSYmGPlMwjPA9dnNojWPDKcNYQbicK+lXsv8l?= =?us-ascii?Q?w8PxxstY6CHIjtiiZJC+sYNY3QvD6goLvA5ajMNB27A+EKxxQ/kpjvCreDKE?= =?us-ascii?Q?758n2qMNxgkYSjj1atgLyhl6UIyKwmyr6jzasPHWsgs7K7IgYRGHBK4SOMqx?= =?us-ascii?Q?9vyfRnU+ODH0IEM0+3oY+o7MW69GTDtBZI5XagXXmfJkgckNF8NfhXBc5xGX?= =?us-ascii?Q?2yngHb3z0e+V+lcnyGLIt+IKGKESESV682hLnRn2dV13lZM2UjmDQ+VI02IS?= =?us-ascii?Q?3yGNTzEFFTvrwz0IxoY9bNDBWxX32CsKx/PyjUYgzIDZFr5xnWHBoDusUOQF?= =?us-ascii?Q?otRYBU5NcIFEKUDOCE6YePc7tk9zkErrsCBln3RQR8r1C3r+vXDKFml519V3?= =?us-ascii?Q?9lXHi7Xhee0WR8vV5C66NvUqckZor7ymHXAcqZNc8L9ej9iklnxBFhcfIKue?= =?us-ascii?Q?6MzoDT5RMETKaj1Lr8jDHiv8cayUnXAdt/t5hFEF47aST6DlNE42wjMsagRy?= =?us-ascii?Q?Qx8C5XGCBAPJV61IiPbna9EcEE77grzdlFKTJutwLcwzwlLtqzs73yvcdryT?= =?us-ascii?Q?0wKrUSoPHT4QU6ryY2c7/gODgBAQv8FqddreLDLa19Pfec1WR0qYh7jBe6g5?= =?us-ascii?Q?G/FRAhqxva1gkcqReaT8UMvtEhGhSIiXdfbdB9btSdODnBg2xHgB5uBeraJy?= =?us-ascii?Q?I28D6GfNPrVt/ZinELNr8azoAyt0nR/mBX2sk3PMbA8Dt7fZM5Y4E7UVy+cI?= =?us-ascii?Q?/mtbkixphugB0314NEgUjMu7U9MD5Abh3AiZiOgyEoRJgcnWFAvhUfD7tuNn?= =?us-ascii?Q?dFpGfFlLJ9P5YwPqvPBQclE+9M48zSrQ7VXKNYKpL8W8JTxp+wHejCgm0e1w?= =?us-ascii?Q?NjrtH/ov9sxIOphiP7fq0P7N/yNiEbjTlLtQtPeHfa2K0JzxHkR01j5cUJZK?= =?us-ascii?Q?2Ux94oVjeOwptfXVzNHl1zENvEkEPeQcM/yurCBsufuM9sx+/zrIgqTPh3av?= =?us-ascii?Q?UG7l7ZQ8+s1wcfaUKDpKUpZaLDQPSZ1yA08vpAlxO06H2GwaPLS99nJJ6r1X?= =?us-ascii?Q?tRcsrstAlDq/smaFCqPB1N6V/eX9bLo58qaWkNpj52shBEqUJolLsKtoPuTB?= =?us-ascii?Q?w5fcdG70bSLMpolES9h5+7v9RVvsbkivNLLOQNhwXmAkfn2CeoGFzPbaqLLK?= =?us-ascii?Q?dg=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f5fba36-4881-49a7-eefb-08d9e01e3095 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2022 16:17:31.7627 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: De94OS7EwPhzyxmWrRMCfbaGqGV6WPXl+Y98YGS+KbCV9PisAjJJBq756IbfJwKBeIj+L7hV3o7k/o6kG22W9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1987 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10238 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 bulkscore=0 mlxscore=0 phishscore=0 suspectscore=0 spamscore=0 mlxlogscore=817 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2201250104 X-Proofpoint-GUID: IF1jYQ5yO2AtfXCSRFvfgG4a3hzRUcXv X-Proofpoint-ORIG-GUID: IF1jYQ5yO2AtfXCSRFvfgG4a3hzRUcXv X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17394 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Ted Zlatanov writes: >=20 > > This may work for some modes but not others. The `next-error' facility > > is opaque to the caller because each mode has to decide what makes sens= e > > in terms of locations and motion to them. So I think trying to expose > > more of the internals and formalize them would limit the ways in which > > it can be useful. >=20 > Skimming this thread, I agree, so I'm closing this bug report. This is _really_ too bad. This has nothing whatsoever to do with any "internals". There's no difficulty in providing a means for a mode to offer Lisp access to the locations, and there's no problem in letting a mode not do that. Not every mode needs to offer this usability. This enhancement would provide an important, useful feature. It's sad that you don't see that, but I expect that in another decade or two Emacs will provide this, or similar. From unknown Thu Aug 14 21:52:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 23 Feb 2022 12:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator