From xemacs-m  Tue Jan  7 19:11:14 1997
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130])
          by xemacs.cs.uiuc.edu (8.8.4/8.8.4) with ESMTP
	  id TAA07085 for <xemacs-beta@xemacs.org>; Tue, 7 Jan 1997 19:11:09 -0600 (CST)
Received: (from hniksic@localhost)
          by jagor.srce.hr (8.8.4/8.8.4)
	  id CAA15882; Wed, 8 Jan 1997 02:07:36 +0100 (MET)
Sender: hniksic@public.srce.hr
To: greg@alphatech.com
Cc: xemacs-beta@xemacs.org (XEmacs beta list)
Subject: Re: scrollbars
References: <9701080035.AA12973@euler.alphatech.com>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: &}4JQk=L;e.~x+|eo]#DGk@x3~ed!.~lZ}YQcYb7f[WL9L'Z*+OyA\nAEL1M(".[qvI#a2E
 6WYI5>>e7'@_)3Ol9p|Nn2wNa/;~06jL*B%tTcn/XvhAu7qeES0\|MF%$;sI#yn1+y"
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 08 Jan 1997 02:07:35 +0100
In-Reply-To: greg@alphatech.com's message of Tue, 7 Jan 1997 19:35:56 -0500
Message-ID: <kigafql5608.fsf@jagor.srce.hr>
Lines: 66
X-Mailer: Red Gnus v0.76/XEmacs 19.14

Greg Klanderman (greg@alphatech.com) wrote:
> Something that's always bugged me is that it seems the size of the
> scrollbar and the scrolling are based on character positions instead
> of lines.

When once asked about this, Chuck Thompson has replied that this is
because of the internal XEmacs code, that is pretty much
character-oriented.  This should be fixable, with a possible slowdown
as a sideeffect (but the slowdown could probably also be prevented
with some sort of caching of line positions).

The problem that bugs *me* dealing with scrollbars (and many other
things) is that the XEmacs display does not seem to be capable of
displaying a part of a line on the top of a window (although this
works for the bottom).  This results in the fact that to see an image
bigger than the window, you must resize the window (or frame).

Any newbie tries to do this with a scrollbar, and the results are
terribly annoying.  This can be well seen when using tm with inline
images.

> scrollbar, the scrolling rate changes abruptly (much slower) when the
> long lines are at the top of the screen.  You would also expect the
> scrollbar to be about half the window height, as there are about 2
> screenfuls of text, but it is much smaller.  When using C-v and M-v or
> the scroll buttons, the size of the scrollbar also changes.  As the
> long lines become visible it gets much larger. (btw this is 19.15b4)

I have noticed these glitches too, and not all of them can be
explained by character-based scrollbars.

> In the gnus article buffer things are even stranger as the text within
> hidden headers seems to effect the scrolling speed.  You can move the
> scroll bar quite far when the hidden text is at the top of the window
> with no scrolling taking place.  Its also annoying that the cursor can
> move inside the hidden headers, instead of jumping over.  You have to
> hit C-n once for every line to get through.

This seems to be a text-properties issue, possibly a defficiency in
XEmacs' implementation of text properties.  AFAIK Gnus uses text-props
for things like invisible text, and we implement them on top of
extents.

Gnus could probably get better performance, as well as behavior, on
XEmacs if it used the native extents, but it would ruin the
compatibility with GNU Emacs.  As Gnus is developed on GNU Emacs, this
is unthinkable.

> Clearly this is a pretty minor problem,

This is a minor problem right now.  But once we wish to implement more
powerful capabilities to XEmacs (like word processing), it will be a
pain.

> but I figured I'd voice it now that I'm on the beta list.  Anyone
> out there know how difficult this is to fix?

The scrollbar glitches you should not be too hard to fix (please
correct me if I'm wrong).  The text properties you mention might be a
problem, and the the display of images and/or big fonts could be hard
to fix.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The end of the world is coming...  SAVE YOUR BUFFERS!

