From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: unnecessary fringe-indicators defcustom creates trouble Date: Sat, 06 Aug 2005 14:36:51 -0400 Message-ID: References: <200507290113.j6T1Drc18126@raven.dms.auburn.edu> <200508010247.j712l3B02940@raven.dms.auburn.edu> <200508012118.j71LI0N06793@raven.dms.auburn.edu> <200508022031.j72KVkP09810@raven.dms.auburn.edu> <200508040103.j74134v11621@raven.dms.auburn.edu> <200508040249.j742nO011803@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1123355196 15628 80.91.229.2 (6 Aug 2005 19:06:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2005 19:06:36 +0000 (UTC) Cc: teirllm@dms.auburn.edu, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 06 21:06:29 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1E1Tzn-0006TV-4b for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2005 21:06:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E1U2i-0004lc-2J for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2005 15:09:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1E1Tzb-0003Id-HE for emacs-devel@gnu.org; Sat, 06 Aug 2005 15:05:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1E1TzM-00038n-3j for emacs-devel@gnu.org; Sat, 06 Aug 2005 15:05:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E1TzI-0002sj-0K for emacs-devel@gnu.org; Sat, 06 Aug 2005 15:05:40 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1E1TmP-0006jQ-6M for emacs-devel@gnu.org; Sat, 06 Aug 2005 14:52:21 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1E1TXP-0002Sn-9D; Sat, 06 Aug 2005 14:36:51 -0400 Original-To: Luc Teirlinck Original-to: Kim F. Storm In-reply-to: <200508040249.j742nO011803@raven.dms.auburn.edu> (message from Luc Teirlinck on Wed, 3 Aug 2005 21:49:24 -0500 (CDT)) 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:41613 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:41613 To be more concrete, enable all boundary indicators, including arrows, to the left. Create an empty buffer. The boundary indicators actually give the impression that the buffer is non-empty. Typing RET does not change the indicators, so you can not tell whether the buffer is empty or not. I think what we are seeing here is that the end-of-buffer indicator goes on the wrong line. It goes at the last nonempty line. I think it should go at the end of the buffer, which (in the case of ending in a newline) is one line further down. Perhaps there should be a different-looking end-of-buffer indicator for the case of ending in a newline. It could look like the normal end-of-buffer indicator rotated 180 degrees, so that it would effectively suggest "the buffer ends just above this line". This is not crucial, but it would make things clearer. Now overscroll a buffer ending in a newline completely. The "Bottom" indicator now suggests that there is an extra blank line at the end of the buffer, whereas there is not. In this one case, the end-of-buffer indicator goes in the right place. But if you assume it's one line too high, as it usually is, you will think the buffer has an extra newline. I wonder whether it would not be more logical to not show any indicators in an empty buffer and to just show an up arrow in a completely overscrolled buffer. You can not see the end of the buffer, it is scrolled out of view. So why indicate it? That would be one consistent thing to do, but I think it is important to indicate buffer ends when they are visible. Making the change I've suggested would also be consistent. Kim, could you implement this change and ack this message? (Others please don't do a reply to this message. If you want to say something further about this, please don't do it as a "reply".)