From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: James Clark Newsgroups: gmane.emacs.devel Subject: Re: Propertizing the minor-mode-alist Date: Wed, 22 Sep 2004 21:02:27 +0700 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <1095861747.7357.491.camel@pineapple.bkk.thaiopensource.com> References: <1095335866.7357.83.camel@pineapple.bkk.thaiopensource.com> <1095388341.7357.93.camel@pineapple.bkk.thaiopensource.com> <1095475837.7357.125.camel@pineapple.bkk.thaiopensource.com> <1095575707.7357.220.camel@pineapple.bkk.thaiopensource.com> <1095647396.7357.281.camel@pineapple.bkk.thaiopensource.com> <1095838242.7357.414.camel@pineapple.bkk.thaiopensource.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1095862193 15559 80.91.229.6 (22 Sep 2004 14:09:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 22 Sep 2004 14:09:53 +0000 (UTC) Cc: "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 22 16:09:40 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CA7i9-0006tI-00 for ; Wed, 22 Sep 2004 16:03:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CA7o7-0008Uj-UY for ged-emacs-devel@m.gmane.org; Wed, 22 Sep 2004 10:09:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CA7o1-0008TY-0L for emacs-devel@gnu.org; Wed, 22 Sep 2004 10:09:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CA7nz-0008TB-Nz for emacs-devel@gnu.org; Wed, 22 Sep 2004 10:09:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CA7nz-0008T8-J7 for emacs-devel@gnu.org; Wed, 22 Sep 2004 10:09:11 -0400 Original-Received: from [161.58.244.53] (helo=thaiopensource.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CA7ha-0006Yq-Hu for emacs-devel@gnu.org; Wed, 22 Sep 2004 10:02:34 -0400 Original-Received: from dmz-1.bkk.thaiopensource.com ([203.130.150.188]) by thaiopensource.com (8.12.11/8.11.2) with ESMTP id i8ME2V1V047173; Wed, 22 Sep 2004 21:02:33 +0700 (ICT) Original-Received: from [192.168.0.100] (home-gw.bkk.thaiopensource.com [203.130.150.187]) by dmz-1.bkk.thaiopensource.com (Postfix) with ESMTP id C7CEEFA03; Wed, 22 Sep 2004 21:02:18 +0700 (ICT) Original-To: Stefan Monnier In-Reply-To: X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.1thaiopen) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27444 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27444 On Wed, 2004-09-22 at 20:23, Stefan Monnier wrote: > > I like the idea of using a C-u prefix to make the next error command go > > to the first error. I can definitely use that. > > > I don't see a good way to make it work with C-x `. nxml-mode presents > > errors using a very different style of UI from compile.el. It's more > > M-x next-error is now "independent" from compile.el. > Of course, this is specific to Emacs-CVS, but you could use this new feature > by providing a next-error-function (that's the name of the new var > introduced to decouple next-error from compile.el). This looks great. Let me just check my understanding here. The doc string talks about "the next error in the current buffer". This means the next error following the error that was last found my the next-error-function, not the next error after point. So to support the next-error-function I need to maintain an additional bit of state saying which error in my buffer, if any, is the current error for the purposes of next error function; if my next-error-function is called with a non-nil RESET, I change the current error to be the first error in the buffer. If the user wanted to use next-error to run through the errors from an XSLT processor, say, instead from nxml-mode, then they would make the compilation buffer be the only one displayed in the frame before calling next-error. Have I misunderstood anything? James