From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: Overlay arrow in *compilation* and *grep* buffers Date: Thu, 28 Apr 2005 23:34:33 +1200 Message-ID: <17008.51785.631924.784654@farnswood.snap.net.nz> References: <01c548ba$Blat.v2.4$e4827900@zahav.net.il> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1114688143 23356 80.91.229.2 (28 Apr 2005 11:35:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 28 Apr 2005 11:35:43 +0000 (UTC) Cc: Juri Linkov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 28 13:35:40 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DR7I8-00069B-5U for ged-emacs-devel@m.gmane.org; Thu, 28 Apr 2005 13:34:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DR7OF-0003Or-DN for ged-emacs-devel@m.gmane.org; Thu, 28 Apr 2005 07:41:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DR7NR-00035E-Mm for emacs-devel@gnu.org; Thu, 28 Apr 2005 07:40:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DR7NQ-00034X-CB for emacs-devel@gnu.org; Thu, 28 Apr 2005 07:40:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DR7NM-00034K-Bq for emacs-devel@gnu.org; Thu, 28 Apr 2005 07:40:12 -0400 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DR7LL-0000SL-Us; Thu, 28 Apr 2005 07:38:08 -0400 Original-Received: from farnswood.snap.net.nz (p250-tnt1.snap.net.nz [202.124.110.250]) by viper.snap.net.nz (Postfix) with ESMTP id B76EB4AC5E5; Thu, 28 Apr 2005 23:33:42 +1200 (NZST) Original-Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 696E162A99; Thu, 28 Apr 2005 12:34:34 +0100 (BST) Original-To: Eli Zaretskii In-Reply-To: <01c548ba$Blat.v2.4$e4827900@zahav.net.il> X-Mailer: VM 7.19 under Emacs 22.0.50.26 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:36475 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36475 > Moreover, next-error scrolls the display to keep the current line at > the top of the window. I think it's a bit silly to mark the with an > arrow a line that is always at the top of its window; such an arrow > might make sense if we do not scroll the window except when the > current line is no longer visible. Perhaps we need a user option to > control these two features (scrolling and arrow) in a way that would > by default prevent scrolling when the arrow is used to show the > current line. I made a similar point on emacs-devel: compile-goto-error Tue, 16 Nov 2004 Juri pointed me to compilation-context-lines and Stefan said: SM> I recently realized that while the 0-context sometimes makes sense for SM> C-x `, the "don't move" behavior would be preferable when getting SM> to an error by using RET or mouse-2 on the actual error text. > Finally, I don't really understand why new features such as this one > get installed while we are in a feature freeze. At the very least, it > should have been discussed (such a discussion could also lead to > better design decisions wrt scrolling). However, I couldn't find > anything related in emacs-devel archives (sorry if I missed > something). They were discussed as part of a thread that started as a bug report on emacs-pretest-bug: fringe arrow conflict between compile and gud? JUAN-LEON Lahoz Garcia Wed, 23 Mar 2005 I guess its a chicken and egg situation but a proper feature freeze that lasted over a year would surely set back development. Nick