From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: new compile command brokeness Date: Wed, 17 Mar 2004 17:42:49 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040317224249.GB12561@fencepost> References: <20040317214527.5f51c28d.occitan@esperanto.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1079563750 30081 80.91.224.253 (17 Mar 2004 22:49:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 17 Mar 2004 22:49:10 +0000 (UTC) Cc: miles@lsi.nec.co.jp, emacs-devel@gnu.org, Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Mar 17 23:49:01 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 1B3jqP-0002DX-00 for ; Wed, 17 Mar 2004 23:49:01 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B3jqO-0002qL-00 for ; Wed, 17 Mar 2004 23:49:00 +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 1B3joi-00035Q-8d for emacs-devel@quimby.gnus.org; Wed, 17 Mar 2004 17:47:16 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B3jod-00035H-KF for emacs-devel@gnu.org; Wed, 17 Mar 2004 17:47:11 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B3jo7-0002nQ-Ro for emacs-devel@gnu.org; Wed, 17 Mar 2004 17:47:10 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B3jo7-0002nL-LQ for emacs-devel@gnu.org; Wed, 17 Mar 2004 17:46:39 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.24) id 1B3jkQ-0006IX-21; Wed, 17 Mar 2004 17:42:50 -0500 Original-To: Daniel Pfeiffer Content-Disposition: inline In-Reply-To: <20040317214527.5f51c28d.occitan@esperanto.org> User-Agent: Mutt/1.3.28i Blat: Foop 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:20559 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20559 On Wed, Mar 17, 2004 at 09:45:27PM +0100, Daniel Pfeiffer wrote: > > If I go to the *compilation* buffer, and use `C-c C-c' on an error > > line, then that succeeds, and subsequent uses of `next-error' also work > > properly. > > Aha, that's a consequence of scrolling along with the output as it pours > in, unless you move the cursor. The (point) in the *compilation* buffer > serves as the indication where the 'current' error is. > > - remember (or check) that we haven't visited an error from this buffer, > and only in that case jump to the beginning Well I'm not sure about the other solutions, but if it's going to scroll the output during execution, it certainly ought to do this. > > BTW another point I noticed is that while the old compile command > > caused the `current error' (the error last selected by next-error) > > to be the top-line in the *compilation* window, the new one doesn't, > > making it something like the 3rd line or so. > > compilation-context-lines defaults to next-screen-context-lines, so as to > be consistent with normal scrolling. For some messages a few preceding > lines are helpful for understanding. Sure. But it needs to be indicated visually somehow; simply skipping next-screen-context-lines from the top of the window is natural for the computer, but extremely awkward for humans. I gather from your reply that you sort of intended the cursor to serve this purpose, but in my case, I have the cursor turned off in inactive windows, even the default hollowed-out cursor is pretty hard to see. > > This makes which error is current much harder to see; if it's desirable > > to not use the top of the window (maybe to see more context?), then I > > think the current error should be highlighted or something. > > That could be done, but not urgently. I suppose people will just get used to > this, like they are to the scrolling overlap. No. It's actually a big problem for me -- it's a major pain reorienting my eye after each next-error -- even when I'm already looking at the previous error in the *compile* buffer (and so am looking at about the right place). -Miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT]