From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two Date: Thu, 5 Jun 2014 14:52:27 -0700 (PDT) Message-ID: <5f61d1ec-4647-4171-bfac-6dd780023695@default> References: <1257238c-02c2-48f6-a4f1-c53674f87734@default> <87y4xbfn45.fsf@lifelogs.com> <87mwdrf3qh.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1402005210 27457 80.91.229.3 (5 Jun 2014 21:53:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Jun 2014 21:53:30 +0000 (UTC) Cc: 17394@debbugs.gnu.org To: Ted Zlatanov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 05 23:53:23 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wsfb9-0002iI-2m for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Jun 2014 23:53:23 +0200 Original-Received: from localhost ([::1]:43906 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wsfb8-00032Z-O9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Jun 2014 17:53:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wsfax-00032N-Hh for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 17:53:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wsfao-0007vz-Kh for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 17:53:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wsfao-0007vs-Gx for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 17:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Wsfan-0006pN-MR for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 17:53:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jun 2014 21:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17394 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17394-submit@debbugs.gnu.org id=B17394.140200516126203 (code B ref 17394); Thu, 05 Jun 2014 21:53:01 +0000 Original-Received: (at 17394) by debbugs.gnu.org; 5 Jun 2014 21:52:41 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 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)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:90088 Archived-At: > 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".]