From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Owen Taylor Newsgroups: gmane.emacs.devel Subject: Re: Gtk scrollbar: thumb too short Date: 27 Mar 2003 16:07:51 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1048799271.15136.69.camel@localhost.localdomain> References: <20030325193739.ZGIN3924.fep01-svc.swip.net@gaffa.gaia.swipnet.se> <1048780121.14517.22.camel@localhost.localdomain> <200303271630.h2RGU1bT028651@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1048799929 17054 80.91.224.249 (27 Mar 2003 21:18:49 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Mar 2003 21:18:49 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Mar 27 22:18:39 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18yelj-0004Q0-00 for ; Thu, 27 Mar 2003 22:18:39 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18yenm-0003Q9-00 for ; Thu, 27 Mar 2003 22:20:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18yel3-0005lN-07 for emacs-devel@quimby.gnus.org; Thu, 27 Mar 2003 16:17:57 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18yeka-0004kZ-00 for emacs-devel@gnu.org; Thu, 27 Mar 2003 16:17:28 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18yekB-0003vd-00 for emacs-devel@gnu.org; Thu, 27 Mar 2003 16:17:03 -0500 Original-Received: from nat-pool-rdu.redhat.com ([66.187.233.200] helo=lacrosse.corp.redhat.com) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18yej3-00033g-00; Thu, 27 Mar 2003 16:15:53 -0500 Original-Received: from landau.devel.redhat.com (landau.devel.redhat.com [172.16.56.103])h2RLFko12071; Thu, 27 Mar 2003 16:15:46 -0500 Original-To: Stefan Monnier In-Reply-To: <200303271630.h2RGU1bT028651@rum.cs.yale.edu> X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Original-cc: rms@gnu.org Original-cc: "Jan D." Original-cc: jody@gnome.org Original-cc: kai.grossjohann@uni-duisburg.de X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:12675 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12675 On Thu, 2003-03-27 at 11:30, Stefan Monnier wrote: > > * I've always found the emacs behavior with respect to the end of the > > buffer quite confusing personally... I think it would be far > > less confusing if the region that was scrolled was actually > > confined to the lines of the buffer (or maybe lines in buffer + 1) > > Less confusing but pretty damn hard. I'll implement it as soon as you > provide me with a moderately efficient function F that maps from > top-of-the-scrollbar-position (in % of the scrollbar size) to > window-start-position (in characters) such that F(100%) ensures > that (point-max) is visible. > > Of course, if the last char of the buffer is a large image, the behavior > will be quite different from the case where the last 100KB of the buffer > are invisible. Which is where the "moderately efficient" constraint > becomes relevant. Well, if _displaying_ the last page of text can be done with reasonable efficiency, you should also be to compute this quantity with reasonable efficiency.... you just start from the end, and scan backwards for newlines and compute the height of each line until you get enough pixels. Then you have to recompute (queue a recomputation) any time there is a change in the buffer that affects those lines. But yes, that's probably reasonably complex to implement and there is no real bound on the amount of text you might have to look at and lay out to compute this quantity. Frankly, I tend to turn off or just not look at the scrollbar because these same issues make it behave in a confusing manner in general. (Presumably, if you have a large chunks of hidden text anywhere in your document, the scrollbar will go whacky.) While writing text editors with pixel based scrollbars is a subject with lots of prior art, I'm under no illusions that Emacs could be switched over without huge changes both to its code and to its efficiency. > > (Emacs-21.2 with Xaw3d seems to be just buggy ... if the user drags > > the thumb of the scrollbar past the end of the buffer it shrinks > > to a smaller size and doesn't come back.) > > Could you describe the bug more precisely. I don't expect the behavior > to be perfect, but "doesn't come back" sounds serious (unless you're just > talking about the size of the thumb: it only decreases while you drag > to avoid nasty "meta-stable" flicker, so the size will only be reset to > the proper value when the drag is over). I am talking about the size of the thumb. Not only does it not come back when dragging (which, while it may be intentional, looks very much like a bug), it also doesn't come back after you release, until you move the scrollbar again. Regards, Owen