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 11:14:51 -0700 (PDT) Message-ID: References: <1257238c-02c2-48f6-a4f1-c53674f87734@default> <87y4xbfn45.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 1401992193 376 80.91.229.3 (5 Jun 2014 18:16:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Jun 2014 18:16:33 +0000 (UTC) To: 17394@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 05 20:16:24 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 1WscDA-000679-DJ for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Jun 2014 20:16:24 +0200 Original-Received: from localhost ([::1]:43222 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WscD9-0008Fk-VB for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Jun 2014 14:16:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WscCx-000840-AZ for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 14:16:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WscCp-0005Ss-7k for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 14:16:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WscCp-0005Sj-4N for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 14:16:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WscCo-0007nQ-HC for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 14:16:02 -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 18:16:02 +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: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org, 17394@debbugs.gnu.org Original-Received: via spool by 17394-submit@debbugs.gnu.org id=B17394.140199211129825 (code B ref 17394); Thu, 05 Jun 2014 18:16:02 +0000 Original-Received: (at 17394) by debbugs.gnu.org; 5 Jun 2014 18:15:11 +0000 Original-Received: from localhost ([127.0.0.1]:46079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WscBu-0007kr-IV for submit@debbugs.gnu.org; Thu, 05 Jun 2014 14:15:10 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:41377) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WscBo-0007k0-H2 for 17394@debbugs.gnu.org; Thu, 05 Jun 2014 14:15:04 -0400 Original-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 Original-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 Original-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 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)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:90076 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. >=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.