From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.bugs Subject: bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two Date: Thu, 05 Jun 2014 17:25:42 -0400 Organization: =?UTF-8?Q?=D0=A2=D0=B5=D0=BE=D0=B4=D0=BE=D1=80_?= =?UTF-8?Q?=D0=97=D0=BB=D0=B0=D1=82=D0=B0=D0=BD=D0=BE=D0=B2?= @ Cienfuegos Message-ID: <87mwdrf3qh.fsf@lifelogs.com> 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 X-Trace: ger.gmane.org 1402003583 9010 80.91.229.3 (5 Jun 2014 21:26:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Jun 2014 21:26:23 +0000 (UTC) Cc: 17394@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 05 23:26:16 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 1WsfAu-0001Mb-KL for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Jun 2014 23:26:16 +0200 Original-Received: from localhost ([::1]:43855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsfAu-0002MR-8I for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Jun 2014 17:26:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsfAl-0002Kd-Vp for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 17:26:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsfAg-0007OJ-Uq for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 17:26:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47289) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsfAg-0007OE-Kg for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 17:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WsfAg-0005ta-83 for bug-gnu-emacs@gnu.org; Thu, 05 Jun 2014 17:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ted Zlatanov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jun 2014 21:26: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: Original-Received: via spool by 17394-submit@debbugs.gnu.org id=B17394.140200355022637 (code B ref 17394); Thu, 05 Jun 2014 21:26:02 +0000 Original-Received: (at 17394) by debbugs.gnu.org; 5 Jun 2014 21:25:50 +0000 Original-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 Original-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 Original-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) Original-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) 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 In-Reply-To: (Drew Adams's message of "Thu, 5 Jun 2014 11:14:51 -0700 (PDT)") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4.50 (gnu/linux) 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:90086 Archived-At: 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