From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: next-error refactoring Date: Wed, 09 Jun 2004 23:19:29 +0300 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87aczcqyb1.fsf@mail.jurta.org> 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 1086813189 13043 80.91.224.253 (9 Jun 2004 20:33:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 9 Jun 2004 20:33:09 +0000 (UTC) Cc: Ted Zlatanov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jun 09 22:32:58 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 1BY9kn-0004Qx-00 for ; Wed, 09 Jun 2004 22:32:57 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BY9kn-0007aN-00 for ; Wed, 09 Jun 2004 22:32:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BY9lR-0004v4-M4 for emacs-devel@quimby.gnus.org; Wed, 09 Jun 2004 16:33:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BY9lN-0004tc-8w for emacs-devel@gnu.org; Wed, 09 Jun 2004 16:33:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BY9lL-0004tD-HC for emacs-devel@gnu.org; Wed, 09 Jun 2004 16:33:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BY9lL-0004t3-Bi for emacs-devel@gnu.org; Wed, 09 Jun 2004 16:33:31 -0400 Original-Received: from [66.33.219.4] (helo=spork.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BY9kU-0003b7-23 for emacs-devel@gnu.org; Wed, 09 Jun 2004 16:32:38 -0400 Original-Received: from mail.jurta.org (80-235-32-115-dsl.mus.estpak.ee [80.235.32.115]) by spork.dreamhost.com (Postfix) with ESMTP id 3F7FE11DC27; Wed, 9 Jun 2004 13:32:17 -0700 (PDT) Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "09 Jun 2004 05:53:03 -0400") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) 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:24782 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24782 Stefan Monnier writes: > 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. I completely agree on the purpose of the "next-error" framework. > So I don=B4t see how it can usefully be applied to functions in a file. This can be applied to functions when their locations are listed in another buffer by commands that operate on function names, for example, `list-tags' (which is not "next-error" capable now), `list-imenu', `list-outlines' (there are no such functions yet, but they would be useful). > 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 no= t, > otherwise people will be annoyed that C-x ` is always captured by their > dired buffer instead of compile, or things like that. I agree. This should be done only when requested specially by users in dired buffers or in buffers created by `find-dired' or `locate'. > 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 sam= ple > code to try and we=B4re not sure what the new behavior should be. I think it's better at least to establish the infrastructure before the next Emacs release than to release it in the current incomplete (though, usable) state, if possible. That means to continue its development at an unhurried= pace, and include it if it will be completely ready before the next release. --=20 Juri Linkov http://www.jurta.org/emacs/