emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scrolling very buggy (slider, arrows) under OS X


From: Stefan Monnier
Subject: Re: scrolling very buggy (slider, arrows) under OS X
Date: 14 Mar 2004 16:34:41 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

> Under OS X, Emacs behaves very strangely with regard to the scrollbars and
> sliders.

I assume you mean the Carbon build (I use a Mac on a regular basis
these days, but not the Carbon side of it, only the X11).

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

By "click" you mean "left-click" (aka mouse-1) ?
Sounds like a bug, indeed, but then I have no idea how scrollbars are
supposed to work under Carbon.

> When the slider is moved, scrolling looks fine at first. However, I can then
> move beyond the document. 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).

That's normal Emacs behavior.  I'll let people argue whether it's a bug or
feature, but I'll point out that (having spent a fair bit of time on the X11
scrollbar code) changing this behavior is very much non-trivial, so until
someone thinks it's important enough to write a patch, it'll stay as it is.

How the patch should work is still very much unclear.

> 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 an old paradigm! Consequently, the size of
> the slider only changes if the document size changes.

Same as above: maybe it's a bug, maybe it's a feature, but I don't know
anyone who has the beginning of a clue for how to change it anyway.

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

Sounds like a bug: maybe Steve Tamm or Yamamoto Mitsuharu's can look into it?


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]