From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: next-error refactoring Date: Tue, 08 Jun 2004 16:31:56 -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> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1086726779 26691 80.91.224.253 (8 Jun 2004 20:32:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Jun 2004 20:32:59 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jun 08 22:32:43 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 1BXnH0-0000Lo-00 for ; Tue, 08 Jun 2004 22:32:42 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BXnH0-0003iB-00 for ; Tue, 08 Jun 2004 22:32:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BXnHb-00036Q-Q9 for emacs-devel@quimby.gnus.org; Tue, 08 Jun 2004 16:33:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BXnGv-0002nB-En for emacs-devel@gnu.org; Tue, 08 Jun 2004 16:32:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BXnGu-0002mg-Jf for emacs-devel@gnu.org; Tue, 08 Jun 2004 16:32:36 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BXnGu-0002mX-F6 for emacs-devel@gnu.org; Tue, 08 Jun 2004 16:32:36 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BXnGH-00041R-QD for emacs-devel@gnu.org; Tue, 08 Jun 2004 16:31:57 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1BXnGG-0005aJ-S9; Tue, 08 Jun 2004 16:31:56 -0400 Original-To: Ted Zlatanov In-reply-to: <4nhdtnqrek.fsf@lifelogs.com> (message from Ted Zlatanov on Mon, 07 Jun 2004 12:11:47 -0400) 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:24742 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24742 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. There is already an easy way to move between functions: C-M-a and C-M-e. However, I see no resemblance between that and next-error. In dired, it could move to the next file. I do see the resemblance between that and next-error. However, it would probably be simpler to define the same keys (more or less) with parallel meanings but completely different code. In W3 it could go back/forward in the history or between links. I think that could perhaps be implemented using the existing next-error mechanism, if that is useful. 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. To use a single set of key bindings, defined in just one place, would be desirable. I don't know whether it is possible. Making each of these modes have good key bindings is the first priority. If it turns out that a single set if bindings will work well for all of them, we could easily write a subroutine to make those bindings in whatever keymap. That would achieve the simplification you are looking for. The rest of the minor mode mechanism would be unnecessary, perhaps even counterproductive. We certainly do not want it to appear *to the user* as a separate minor mode. That would only be clutter, and suggest to the user that he might want to consider turning the minor mode off, which would always be a mistake.