GNU bug report logs - #17394
24.4.50; enhancement request: split `next-error-function' functionality in two

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Severity: wishlist; Reported by: Drew Adams <drew.adams@HIDDEN>; dated Sat, 3 May 2014 04:32:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 17394 <at> debbugs.gnu.org:


Received: (at 17394) by debbugs.gnu.org; 5 Jun 2014 21:52:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 05 17:52:41 2014
Received: from localhost ([127.0.0.1]:46180 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WsfaS-0006oU-AD
	for submit <at> 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 <drew.adams@HIDDEN>) id 1WsfaP-0006oC-0x
 for 17394 <at> 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 <drew.adams@HIDDEN>
To: Ted Zlatanov <tzz@HIDDEN>
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@HIDDEN> <ffa84ddb-a9df-4bb8-8aa7-4e5af5bd2a88@default>
 <87mwdrf3qh.fsf@HIDDEN>
In-Reply-To: <87mwdrf3qh.fsf@HIDDEN>
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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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".]




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17394; Package emacs. Full text available.

Message received at 17394 <at> debbugs.gnu.org:


Received: (at 17394) by debbugs.gnu.org; 5 Jun 2014 21:25:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 05 17:25:50 2014
Received: from localhost ([127.0.0.1]:46166 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WsfAT-0005t2-9P
	for submit <at> 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 <tzz@HIDDEN>) id 1WsfAQ-0005sl-Ib
 for 17394 <at> 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 <at> 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 <multiple recipients>
 (version=TLSv1.2 cipher=RC4-SHA bits=128/128);
 Thu, 05 Jun 2014 14:25:40 -0700 (PDT)
From: Ted Zlatanov <tzz@HIDDEN>
To: Drew Adams <drew.adams@HIDDEN>
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@HIDDEN>
 <ffa84ddb-a9df-4bb8-8aa7-4e5af5bd2a88@default>
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: <ffa84ddb-a9df-4bb8-8aa7-4e5af5bd2a88@default> (Drew Adams's
 message of "Thu, 5 Jun 2014 11:14:51 -0700 (PDT)")
Message-ID: <87mwdrf3qh.fsf@HIDDEN>
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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

On Thu, 5 Jun 2014 11:14:51 -0700 (PDT) Drew Adams <drew.adams@HIDDEN> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17394; Package emacs. Full text available.

Message received at 17394 <at> debbugs.gnu.org:


Received: (at 17394) by debbugs.gnu.org; 5 Jun 2014 18:15:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 05 14:15:10 2014
Received: from localhost ([127.0.0.1]:46079 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WscBu-0007kr-IV
	for submit <at> debbugs.gnu.org; Thu, 05 Jun 2014 14:15:10 -0400
Received: from userp1040.oracle.com ([156.151.31.81]:41377)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <drew.adams@HIDDEN>) id 1WscBo-0007k0-H2
 for 17394 <at> debbugs.gnu.org; Thu, 05 Jun 2014 14:15:04 -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: <ffa84ddb-a9df-4bb8-8aa7-4e5af5bd2a88@default>
Date: Thu, 5 Jun 2014 11:14:51 -0700 (PDT)
From: Drew Adams <drew.adams@HIDDEN>
To: bug-gnu-emacs@HIDDEN, 17394 <at> 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@HIDDEN>
In-Reply-To: <87y4xbfn45.fsf@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.
>=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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17394; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 5 Jun 2014 18:15:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 05 14:15:46 2014
Received: from localhost ([127.0.0.1]:46085 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WscCT-0007mL-ON
	for submit <at> 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 <drew.adams@HIDDEN>) id 1WscCN-0007lu-Re
 for submit <at> 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 <drew.adams@HIDDEN>) id 1WscC9-0005LF-TP
 for submit <at> 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 <drew.adams@HIDDEN>) id 1WscC9-0005LA-RW
 for submit <at> 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 <drew.adams@HIDDEN>) id 1WscC1-0007Yp-O9
 for bug-gnu-emacs@HIDDEN; Thu, 05 Jun 2014 14:15:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <drew.adams@HIDDEN>) id 1WscBt-0005AL-Hf
 for bug-gnu-emacs@HIDDEN; 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 <drew.adams@HIDDEN>) id 1WscBt-000597-Ap
 for bug-gnu-emacs@HIDDEN; 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: <ffa84ddb-a9df-4bb8-8aa7-4e5af5bd2a88@default>
Date: Thu, 5 Jun 2014 11:14:51 -0700 (PDT)
From: Drew Adams <drew.adams@HIDDEN>
To: bug-gnu-emacs@HIDDEN, 17394 <at> 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@HIDDEN>
In-Reply-To: <87y4xbfn45.fsf@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17394; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 5 Jun 2014 14:27:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 05 10:27:57 2014
Received: from localhost ([127.0.0.1]:45823 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WsYe0-0006yJ-S8
	for submit <at> 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 <geb-bug-gnu-emacs@HIDDEN>) id 1WsYdv-0006xx-F3
 for submit <at> 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 <geb-bug-gnu-emacs@HIDDEN>) id 1WsYdj-0002Io-V2
 for submit <at> 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 <geb-bug-gnu-emacs@HIDDEN>) id 1WsYdj-0002Ik-Si
 for submit <at> 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 <geb-bug-gnu-emacs@HIDDEN>) id 1WsYdd-0006A7-L7
 for bug-gnu-emacs@HIDDEN; Thu, 05 Jun 2014 10:27:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <geb-bug-gnu-emacs@HIDDEN>) id 1WsYdX-0002Ch-Bo
 for bug-gnu-emacs@HIDDEN; 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 <geb-bug-gnu-emacs@HIDDEN>) id 1WsYdX-0002Bm-5W
 for bug-gnu-emacs@HIDDEN; Thu, 05 Jun 2014 10:27:23 -0400
Received: from list by plane.gmane.org with local (Exim 4.69)
 (envelope-from <geb-bug-gnu-emacs@HIDDEN>) id 1WsYdP-0005OV-Fz
 for bug-gnu-emacs@HIDDEN; 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 <bug-gnu-emacs@HIDDEN>; 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 <bug-gnu-emacs@HIDDEN>; Thu, 05 Jun 2014 16:27:15 +0200
X-Injected-Via-Gmane: http://gmane.org/
Mail-Followup-To: bug-gnu-emacs@HIDDEN
To: bug-gnu-emacs@HIDDEN
From: Ted Zlatanov <tzz@HIDDEN>
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@HIDDEN>
References: <1257238c-02c2-48f6-a4f1-c53674f87734@default>
Mime-Version: 1.0
Content-Type: text/plain
X-Complaints-To: usenet@HIDDEN
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: bug-gnu-emacs@HIDDEN
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.1 (----)

On Fri, 2 May 2014 21:30:41 -0700 (PDT) Drew Adams <drew.adams@HIDDEN> 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17394; Package emacs. Full text available.

Message received at 17394 <at> debbugs.gnu.org:


Received: (at 17394) by debbugs.gnu.org; 3 May 2014 21:41:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 03 17:41:58 2014
Received: from localhost ([127.0.0.1]:50041 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wghh0-0005u4-AM
	for submit <at> 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 <drew.adams@HIDDEN>) id 1Wghgx-0005to-CV
 for 17394 <at> 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 <at> 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 <at> 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 <at> 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 <drew.adams@HIDDEN>
To: 17394 <at> 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>
 <a617bc3c-ae68-4ed9-8114-b6a038f8a56b@default>
In-Reply-To: <a617bc3c-ae68-4ed9-8114-b6a038f8a56b@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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17394; Package emacs. Full text available.

Message received at 17394 <at> debbugs.gnu.org:


Received: (at 17394) by debbugs.gnu.org; 3 May 2014 21:38:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 03 17:38:53 2014
Received: from localhost ([127.0.0.1]:50031 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wghe1-0005nu-3o
	for submit <at> 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 <drew.adams@HIDDEN>) id 1Wghdz-0005na-20
 for 17394 <at> 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 <at> 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 <at> 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 <at> debbugs.gnu.org>; Sat, 3 May 2014 21:38:43 GMT
MIME-Version: 1.0
Message-ID: <a617bc3c-ae68-4ed9-8114-b6a038f8a56b@default>
Date: Sat, 3 May 2014 14:38:43 -0700 (PDT)
From: Drew Adams <drew.adams@HIDDEN>
To: 17394 <at> 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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17394; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 3 May 2014 04:31:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 03 00:31:22 2014
Received: from localhost ([127.0.0.1]:49006 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WgRbe-00015B-Ce
	for submit <at> 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 <drew.adams@HIDDEN>) id 1WgRbb-00014p-5i
 for submit <at> 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 <drew.adams@HIDDEN>) id 1WgRbL-0004A0-I0
 for submit <at> 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 <drew.adams@HIDDEN>) id 1WgRbL-00049w-F8
 for submit <at> 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 <drew.adams@HIDDEN>) id 1WgRbC-0004pB-MU
 for bug-gnu-emacs@HIDDEN; Sat, 03 May 2014 00:31:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <drew.adams@HIDDEN>) id 1WgRb3-0003oA-Vj
 for bug-gnu-emacs@HIDDEN; 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 <drew.adams@HIDDEN>) id 1WgRb3-0003o4-P4
 for bug-gnu-emacs@HIDDEN; 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 <bug-gnu-emacs@HIDDEN>; 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 <bug-gnu-emacs@HIDDEN>; 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 <bug-gnu-emacs@HIDDEN>; 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 <drew.adams@HIDDEN>
To: bug-gnu-emacs@HIDDEN
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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@HIDDEN=
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''




Acknowledgement sent to Drew Adams <drew.adams@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#17394; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.