Re: Aquamacs distro for OS X like behavior

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> 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