From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#3576: 23.0.94; scroll bar scrolls past eob - keeps scrolling Date: Tue, 16 Jun 2009 17:34:56 -0700 Message-ID: <8BA1212D193F486090CFAC50E0C100E3@us.oracle.com> References: <929A2B1B4DED49D28DDCAD61181807D0@us.oracle.com> <83prd5bdut.fsf@gnu.org> <83ocspbaug.fsf@gnu.org> <6D79C4AC04B54A39ADC5C3E57C1CC150@us.oracle.com> <83my88c22e.fsf@gnu.org> <83k53cavee.fsf@gnu.org> Reply-To: Drew Adams , 3576@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1245200262 27022 80.91.229.12 (17 Jun 2009 00:57:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Jun 2009 00:57:42 +0000 (UTC) Cc: 3576@emacsbugs.donarmstrong.com To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 17 02:57:36 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MGjT4-00044g-I5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Jun 2009 02:57:34 +0200 Original-Received: from localhost ([127.0.0.1]:56433 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGjT3-0003yj-MS for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Jun 2009 20:57:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGjSy-0003vQ-Qa for bug-gnu-emacs@gnu.org; Tue, 16 Jun 2009 20:57:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGjSu-0003ky-DN for bug-gnu-emacs@gnu.org; Tue, 16 Jun 2009 20:57:28 -0400 Original-Received: from [199.232.76.173] (port=56700 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGjSu-0003kh-4K for bug-gnu-emacs@gnu.org; Tue, 16 Jun 2009 20:57:24 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:60366) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MGjSt-0004zj-EJ for bug-gnu-emacs@gnu.org; Tue, 16 Jun 2009 20:57:23 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5H0vKj6015841; Tue, 16 Jun 2009 17:57:21 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n5H0e4DJ012947; Tue, 16 Jun 2009 17:40:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 17 Jun 2009 00:40:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 3576 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 3576-submit@emacsbugs.donarmstrong.com id=B3576.124519890412177 (code B ref 3576); Wed, 17 Jun 2009 00:40:04 +0000 Original-Received: (at 3576) by emacsbugs.donarmstrong.com; 17 Jun 2009 00:35:04 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5H0Ywpf012119 for <3576@emacsbugs.donarmstrong.com>; Tue, 16 Jun 2009 17:34:59 -0700 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5H0YoCu019410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jun 2009 00:34:51 GMT Original-Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5H0a6tF014857; Wed, 17 Jun 2009 00:36:07 GMT Original-Received: from dradamslap1 (/141.144.80.217) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jun 2009 17:34:48 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <83k53cavee.fsf@gnu.org> Thread-Index: Acnur9SVn0hMx6aNRZ24mYncycNHjwAMqo2A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4A383A29.0094:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Tue, 16 Jun 2009 20:57:28 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:28753 Archived-At: > > > Yep. Emacs 21.4 stops on the last text line, Emacs 22.3 > > > and 23.0.94 stop on EOB. > > > > What do you mean by "stop on EOB"? If end of the buffer is > > the newline immediately following the last line of non-newline > > chars, then how can showing up to a screenful of blank vertical > > space be considered "stopping at EOB"? > > EOB == (point-max) > > Emacs 21.4 stops when the last line of the buffer is at the topmost > line of the window. Emacs 22 and 23 put EOB on the topmost line of > the window. Emacs 22/23 does not put the last non-whitespace line at the top of the window. It apparently puts (point-max) at the top, which in most cases (e.g. Lisp libraries) is a line with only a newline character. Why should they put the last line (whitespace or not) at the _top_ of the window, instead of the bottom of the window? Why would someone want to see an extra screen of blank space, with the final newline at the top of the window? That just doesn't seem very user friendly. Do you know of a use case for that, which might justify that as the standard behavior? If not, I propose that this be fixed by returning to the Emacs 20/21 behavior. > > Do you mean that it decides that the final newline has as a > > right to be scrolled to the top of the screen? Is that what > > "stopping at eob" means? > > > > If this is just an unfortunate result of the way things > > happen to be currently implemented, that's one thing. > > But I find it hard to believe that this would have been a > > design goal - that someone would start out intentionally to > > produce this behavior. What's the advantage or use case? > > > > I've never seen this behavior in any other app (though I'm > > sure you'll come up with some other app that has the same > > behavior). ;-) > > I was just stating the fact, not embracing it. > > Now, can you please stop shouting at me? My only sin is that I > confirmed your report. No one has shouted at you. Don't be so defensive. This is not about you, at all. It's merely a bug report. Thank you for confirming it.