Re: Keys when menu-bar is active?

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/address@hidden> writes:
> 
> >> * When scrolling down, scrolling doesn't stop when the end of the 
> >>   scrollbar is reached.
> >
> > You mean it only stops when the last char of the buffer is at the very top
> > of the screen.  I don't think it's a feature.
> 
> The "thumb" stops when the last line is shown on screen, but the
> scrolling doesn't stop until the last char is at the top of the
> screen, yes.

Yes, that was the behavior of Emacs-20's scrollbar and I tried to
preserve it.

> >> * The scrolling bar changes size depending on where you are in the
> >>   buffer, it seems to depend on how many lines are visible on the
> >>   screen (i.e. long lines change things).
> >
> > It reflects he number of chars visible compared to the total number of 
> > chars.
> > That's pretty standard (Xaw with xterm does the same except it's based
> > on lines instead of chars.  Since Emacs doesn't keep track of the number
> > of lines, it would be costly to recompute it all the time).
> 
> The Xaw programs I've used (mostly xterm though) doesn't behave like
> Emacs, so the experience is a little different.

Yes, xterm uses lines, Emacs uses chars, the two programs deal with
different things so they behave differently.  I'm surprised users
would be surprised by such differences.

> >> * Due to the changing size, you can't use it to reliably indicate
> >>   how many lines are above you and how many lines below you.
> > I'm not sure I understand.  It does reliably indicate something else.
> Yes, ok.  Since it doesn't indicate the same thing as in other
> programs using Xaw widgets, it is not inutive what it does indicate.

They both indicate via the thumb size some approximate idea of
the fraction of text that's visible.
Admittedly, what we really would want is that the "fraction" is
not based on lines (as in xterm) or on chars (as in Emacs right now)
but on vertical pixel size.  That's actually what xterm does
(since its lines all have the same pixel height), but doing that
in Emacs would be awfully costly (you'd have to render the whole
buffer in order to find the total pixel size).

> >> * Scroll-one-line-at-a-time doesn't move the cursor (ordinary
> >>   scrolling does).
> >
> > That's not related directly to the scrollbar.  Same thing happens
> > with M-v and C-v.  You want something like scroll-in-place.
> 
> Maybe it was because scroll-one-line-at-a-time didn't recenter the
> screen, if it does it should also move the point.

I don't understand what you're saying here.  With M-v and C-v and
"Scroll-one-line-at-a-time" the cursor is only moved if it is
necessary (given the fact that the cursor always has to be visible).
They call the exact same function and thus function exactly the same,
except for the number of lines that are scrolled.

> I think all my issues would be taken care of GTK support in Emacs, so
> I don't think fixing the Xaw widgets should have very high priority.

The issues you have are mostly unrelated to the toolkit being used.
The toolkit influences the visual appearance of the scrollbar,
as well as the kind of operations triggered when clicking on the
various parts of the widget, but the size and position of the thumb
is completely under the control of Emacs' C code.

So I don't expect the GTK support to magically change things the
way you want them.


        Stefan