Re: Keys when menu-bar is active?

[Simon Josefsson]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

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

Oh, ok.  Backwards compatibility is good, I guess.

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

Can't the scrollbar base its size on the previous rendering of the
screen?

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

My point was that one-line-at-a-time using the scrollbar didn't work
the same as M-v and C-v, but I can't seem to reproduce this now. Hm.

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

Hm.  Ah, I understand.  I guess I was assuming that the GTK code would
make the Emacs window into a GTK Text Widget (where the movement of
the scrollbar is fairly automatic), but I guess the GTK code will only
use the GTK scroll bar widget and preserve the current standard Emacs
window.