From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: dapfy@t-online.de (Daniel Pfeiffer) Newsgroups: gmane.emacs.devel Subject: Re: new compile command doesn't coalesce errors on the same line Date: Sat, 20 Mar 2004 20:33:02 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040320203302.2e32741a.occitan@esperanto.org> References: <20040317215208.5b0cb3e2.occitan@esperanto.org> <20040317224726.GC12561@fencepost> <20040320074137.2ea2c886.occitan@esperanto.org> <20040320082616.GA11718@fencepost> Reply-To: Daniel Pfeiffer NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1079811876 2272 80.91.224.253 (20 Mar 2004 19:44:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 20 Mar 2004 19:44:36 +0000 (UTC) Cc: miles@lsi.nec.co.jp, miles@gnu.org, emacs-devel@gnu.org, rms@gnu.org, Stefan Monnier Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Mar 20 20:44:28 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 1B4mOS-00009e-00 for ; Sat, 20 Mar 2004 20:44:28 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B4mOS-000497-00 for ; Sat, 20 Mar 2004 20:44:28 +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 1B4mNv-0004Vg-Ke for emacs-devel@quimby.gnus.org; Sat, 20 Mar 2004 14:43:55 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B4mNd-0004SU-OD for emacs-devel@gnu.org; Sat, 20 Mar 2004 14:43:37 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B4mNF-0004FU-1A for emacs-devel@gnu.org; Sat, 20 Mar 2004 14:43:33 -0500 Original-Received: from [194.25.134.19] (helo=mailout06.sul.t-online.com) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B4mM4-0003zZ-Ny; Sat, 20 Mar 2004 14:42:00 -0500 Original-Received: from fwd05.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1B4mLz-0000mG-00; Sat, 20 Mar 2004 20:41:55 +0100 Original-Received: from pfdabpc.inhouse.start.de (Jr4IfOZbZeu-fa1tPdsE1gB38mR5sd2hlWgpu5C9SrxkQOf+AwsWcw@[217.234.28.149]) by fwd05.sul.t-online.com with smtp id 1B4mLg-1FnBpo0; Sat, 20 Mar 2004 20:41:36 +0100 Original-To: Miles Bader In-Reply-To: <20040320082616.GA11718@fencepost> X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-suse-linux) X-Seen: false X-ID: Jr4IfOZbZeu-fa1tPdsE1gB38mR5sd2hlWgpu5C9SrxkQOf+AwsWcw 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:20650 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20650 Hi Miles, I'm not sure a compiler with buggy messages should force the default value for compilation-skip-visited. But gcc is probably the most frequently used program inside compile, so I'd already accepted what looks like the majority verdict, of making this option be t. For those who would like to set it to nil, here's an example of four messages pertaining to one line, and only two are directly related: $ perl -we '$x = foo; print "$y\n"' Unquoted string "foo" may clash with future reserved word at -e line 1. Name "main::y" used only once: possible typo at -e line 1. Name "main::x" used only once: possible typo at -e line 1. Use of uninitialized value in concatenation (.) or string at -e line 1. Miles Bader skribis: > On Sat, Mar 20, 2004 at 07:41:37AM +0100, Daniel Pfeiffer wrote: > > > Meanwhile, to the extent I can figure it out, I think this is indeed > > > something else. Let's just change the code so as to treat > > > contiguous errors as one. > > > > How contiguous do they have to be? How many lines apart may they be? > > Keep this in mind: Where the old compile was bound to line-beginnings, the > > new one can match a location anywhere on a line, even several different > > kinds on the same line as in > > > > What would we gain? Why would I want to go to the same spot again if it > > is mentioned 3 lines down, but not when it is mentioned on the next line? > > It has to _at least_ handle correctly the cases the old compile command did. And those are? I asked some clear questions. What is it you want that my option can not give you? And how do you want to handle the example I gave (recognizing multiple locations on a line), which you didn't answer? > Geez, I'm beginning to think it would be easier just to put the old one > back. Geez, you've got your very constructive day again! The old one was awful, not differentiating an error from a warning or info, clueless about multiple locations on a line, randomly pretending there's no error on the current line even though it's highlighted or sometimes even going to a wrong file... coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn Daniel Pfeiffer -- lerne / learn / apprends / läramå / ucz się Esperanto: http://lernu.net/