From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: next-error refactoring Date: 09 Jun 2004 05:53:03 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040503.071327.124836670.Takaaki.Ota@am.sony.com> <20040504.075437.207586641.Takaaki.Ota@am.sony.com> <87llk552oz.fsf@mail.jurta.org> <87isf6e7ji.fsf@mail.jurta.org> <87iseg4x5d.fsf@mail.jurta.org> <4npt8oeet9.fsf_-_@lifelogs.com> <4nd64j6u3p.fsf@lifelogs.com> <4n3c5c64mx.fsf@lifelogs.com> <4nhdtnqrek.fsf@lifelogs.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1086774924 21844 80.91.224.253 (9 Jun 2004 09:55:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 9 Jun 2004 09:55:24 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jun 09 11:55:18 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BXzni-0001V5-00 for ; Wed, 09 Jun 2004 11:55:18 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BXzni-0006L5-00 for ; Wed, 09 Jun 2004 11:55:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BXzoL-00045K-M7 for emacs-devel@quimby.gnus.org; Wed, 09 Jun 2004 05:55:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BXzoE-00045F-KH for emacs-devel@gnu.org; Wed, 09 Jun 2004 05:55:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BXzoE-000453-5T for emacs-devel@gnu.org; Wed, 09 Jun 2004 05:55:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BXzoE-000450-3k for emacs-devel@gnu.org; Wed, 09 Jun 2004 05:55:50 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BXznL-0006Hj-MG for emacs-devel@gnu.org; Wed, 09 Jun 2004 05:54:55 -0400 Original-Received: from vor.iro.umontreal.ca (vor.iro.umontreal.ca [132.204.24.42]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 268A1B30475; Wed, 9 Jun 2004 05:53:27 -0400 (EDT) Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id 6B3433C63E; Wed, 9 Jun 2004 05:53:03 -0400 (EDT) Original-To: Ted Zlatanov In-Reply-To: <4nhdtnqrek.fsf@lifelogs.com> Original-Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 5) X-MailScanner-From: monnier@iro.umontreal.ca X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:24763 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24763 > 1) There are many modes that can benefit from a next-error (or > whatever it's called by then) approach. In code, for instance, > next-error could move between functions. In dired, it could move > to the next file. In W3 it could go back/forward in the history > or between links. To me the concept of "next-error" refers to something that has the following properties: - every entry in the list of things to step through refers to a location in another buffer. - you want to step through the locations referred to rather than only stepping through the entries themselves. So I don=B4t see how it can usefully be applied to functions in a file. I see that it can be handy to C-x ` through a list of files in dired in some particular cases, tho. But we then need to design some way to distinguish between buffers where this is common and those where it is not, otherwise people will be annoyed that C-x ` is always captured by their dired buffer instead of compile, or things like that. We=B4ve already seen such problems with my adding C-x ` support to diff-mode. > 2) Approaching next-error as we do now, in a haphazard fashion, > implemented specifically in every mode that needs to use it, is > painful for the developer. It's much easier to provide hooks, a > keymap, and all the other niceties of a standalone minor mode. > Users will certainly appreciate that too. Also, if and when > next-error changes, developers won't have to change their code. I agree that more of the next-error code should be in the generic part of the code (all the window-management comes to mind), but I also think this is better done post-21.4. Especially since we still don=B4t have any sample code to try and we=B4re not sure what the new behavior should be. Stefan