From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Aquamacs distro for OS X like behavior Date: Wed, 06 Apr 2005 10:08:20 -0400 Message-ID: <87vf70ausz.fsf-monnier+emacs@gnu.org> References: <7ca1709813602da58a139cee58fb4c63@gmail.com> <3b9c4e2f33d37fed55f640dcafbc8d65@gmail.com> <87is31i8jq.fsf-monnier+emacs@gnu.org> <0ba853825b580f74347416c2c0b4a169@gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1112796661 19973 80.91.229.2 (6 Apr 2005 14:11:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Apr 2005 14:11:01 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 06 16:10:57 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DJBCi-0003zI-Mf for ged-emacs-devel@m.gmane.org; Wed, 06 Apr 2005 16:08:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DJAlp-000427-3V for ged-emacs-devel@m.gmane.org; Wed, 06 Apr 2005 09:40:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DJAlA-0003s1-Gt for emacs-devel@gnu.org; Wed, 06 Apr 2005 09:39:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DJAl9-0003rR-Ue for emacs-devel@gnu.org; Wed, 06 Apr 2005 09:39:55 -0400 Original-Received: from [209.226.175.34] (helo=tomts13-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DJBD5-0002ZH-8H for emacs-devel@gnu.org; Wed, 06 Apr 2005 10:08:47 -0400 Original-Received: from alfajor ([67.68.217.126]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050406140820.DXD25800.tomts13-srv.bellnexxia.net@alfajor>; Wed, 6 Apr 2005 10:08:20 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id 74417D75EC; Wed, 6 Apr 2005 10:08:20 -0400 (EDT) Original-To: David Reitter In-Reply-To: <0ba853825b580f74347416c2c0b4a169@gmail.com> (David Reitter's message of "Wed, 6 Apr 2005 14:03:06 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:35630 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:35630 >>> for example to handle scrollbars correctly. >> Please report any complaint you have against the scrollbar with >> M-x report-emacs-bug. > I have reported this in various places, for example on > emacs-pretest-bugs here: > http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-03/ msg00110.html > and Steven Tamm and Yamamoto Mitsuharu have been made aware of it a while > ago. I have no plans to report the same problem again :-) Sorry I missed it. I have no knowledge of Carbon Emacs, but I do have a lot of experience trying to get non-Xaw scrollbars to work with Emacs. So I can answer some of the issues you raise in your post: > Under OS X, Emacs behaves very strangely with regard to the scrollbars and > sliders. When you just click on a slider without moving it (after you've > scrolled to the middle of the document), you will see that the text > scrolls right away, often far beyond the document. Intended behavior > would be not to do anything. The description of the behavior is not sufficiently precise for me to be sure, but it looks like a genuine bug. I'm not sure what you mean by "far beyond the document", tho. > When the slider is moved, scrolling looks fine at first. However, I can > then move beyond the document. You mean you can scroll til the point where the very end of the document is at the very top of the window. That's normal Emacs behavior. And there are sound technical reasons why it's done this way. > Good behavior under OS X would be to stop scrolling just when one line > after the document is located at the bottom end of the screen > (i.e. frame). Other than being slightly different, in what case is it a problem? The behavior you want is a behavior I find inconvenient in many cases (e.g. I find it unpleasant to type text on the very last line of a window, and I sometimes like to move the text higher up in the window (even if it's at the bottom of the buffer) so I can align it on screen with some other window's text). I sometimes actually even wish the same would hold for the beginning of the buffer (being able to place (point-min) at the bottom of the window). > Also, during scrolling, the size of the slider changes. That should never > be, as the size indicates the length of the document in relation to the size > of the whole scrollbar. That's exactly what it represent: the ratio slider/total is the same as the ratio shownchars/buffercharsize. But depending on where you are in the buffer the window will not always show the same number of chars, so the size of the slider changes accordingly. In order for the slider to have a fixed size independent from the position in the buffer it would have to show "shownpixels/bufferpixelsize". Problem is that bufferpixelsize is very costly to compute so we currently can't do that. > That's an old paradigm! Consequently, the size of the slider only changes > if the document size changes. "Old paradigm" is not an argument I care about. I still haven't heard of any scenario where the current behavior causes an actual problem. The worst I've heard is that users are surprised and then go on with their life. I've never heard of any user actually getting confused by it. I'm not claiming that the current behavior is a feature, but I'm just saying that the cost of a fix is just too high compared to the very minor improvement it would bring. Maybe the situation will be different ten years from now, but before then I don't see things changing on this front. BTW, in Emacs-CVS you can actually "try it out" by calling `count-screen-lines'. On reasonably large buffers, it takes a while. Also the bufferpixelsize can be changed by font-lock fontification, so we'd have to throw away jit-lock and go back to plain font-lock. > Furthermore, clicking on one of the little arrows doesn't result in an > immediate scroll action (one line). It only scrolls when the mouse button is > released. Good behavior would be to scroll as soon as the button is down, > and then scroll again (line by line, but continuously), after a short > delay -- just like pressing a key will repeat that letter on and on after > a delay. That looks like a genuine bug. Stefan