From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: compilation-forget-errors still used by tex-mode.el Date: 19 Mar 2004 11:33:09 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1079688965 11957 80.91.224.253 (19 Mar 2004 09:36:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 19 Mar 2004 09:36:05 +0000 (UTC) Cc: Markus Rost , emacs-devel@gnu.org, occitan@esperanto.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Mar 19 10:35:57 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 1B4GQ1-0003U2-00 for ; Fri, 19 Mar 2004 10:35:57 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B4GQ1-0003pv-00 for ; Fri, 19 Mar 2004 10:35:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B4GPD-0000VS-NL for emacs-devel@quimby.gnus.org; Fri, 19 Mar 2004 04:35:07 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B4GOd-0000QN-I3 for emacs-devel@gnu.org; Fri, 19 Mar 2004 04:34:31 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B4GO5-0000ID-6j for emacs-devel@gnu.org; Fri, 19 Mar 2004 04:34:28 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.30) id 1B4GNj-000056-4i for emacs-devel@gnu.org; Fri, 19 Mar 2004 04:33:35 -0500 Original-Received: (qmail 39644 invoked from network); 19 Mar 2004 09:33:28 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 19 Mar 2004 09:33:28 -0000 Original-To: Stefan Monnier In-Reply-To: Original-Lines: 59 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:20602 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20602 Stefan Monnier writes: > > - keep a marker to the next position (strange to not find the next error > > where the cursor is, though) > > That's the old way. It's actually not so strange in practice. > And it allows the user to move around in the *compile* buffer without > losing track of the "current error" (I'm not sure how important this is, > but I suspect that some people rely on this on a regular basis). Sometimes it would be nice if next error followed the cursor, other times not. Problem is to say when you want one or the other behaviour. There should be commands for both, e.g. C-x ` (next-error) takes next error independently of point, while some other command (I'd prefer RET, but that's another, old, discussion) takes you to the error on the current line (or next error following it (and moves next-error marker accordingly). > > > - generally wrap around to the begining if any errors were skipped, and > > only signal this error if none are left (seems the most useful and > > consistent solution :-) > > This indeed seems like an option, although I'm not sure whether people would > find it helpful or annoying. So it should be an option. It should be off in basic compilation buffers, but for some modes, it might be quite useful. F.ex. in grep, where you could jump to specific occurrences first (e.g. to fix a declaration or prototype), and then go through the rest afterwards (to fix uses). > If it's not too much coding, it might be > worth trying it out. > In that case the "beginning of errors" could be encoded by marking all > previous errors as visited. > > To be honest the idea of annotating every error with a `visited' flag > doesn't sound too great. As I said, it might be useful, but there should definitely be some way to turn it off (or clear the visited flags). > > My current patch basically reproduces the behavior of the old code: > it re-introduces `compilation-parsing-end' and uses it as the "current > error" marker. While I think that using a marker is the best option and > that re-introducing `compilation-parsing-end' for compatibility purposes is > right as well, I'm not convinced that merging the two is such a hot idea. > We should maybe just introduce a new `compilation-current-error' marker > instead and keep `compilation-parsing-end' for compatibility only. And add compilation-current-error to overlay-arrow-variable-list :-) -- Kim F. Storm http://www.cua.dk