Re: redisplay, events, and gutters
>>>> On January 28, 2011 Stephen J Turnbull
<stephen(a)xemacs.org> wrote:
Mike Kupfer writes:
> Hmm. mouse-drag-modeline works by identifying the window that the
> modeline is for, and then shrinking or growing the window by 1 or more
> lines. It calculates the number of lines to grow/shrink by comparing
> the Y position of the mouse with the current boundaries of the window.
Doesn't that seem like a hack to you? IMO, a real GUI app would
simply move the modeline by as many pixels as you dragged the mouse,
and clip the Emacs windows accordingly (perhaps leaving partial lines
exposed).
that's easily achievable by dropping this line in mouse-drag-modeline:
(setq growth (/ growth default-line-height))
and calling enlarge-window-pixels rather than enlarge-window.
but please keep the default to move by whole line increments.
> I'll see if mouse-drag-modeline can be made to work with
> event-window-y-pixel.
that seems like it will not be an easy to make work or an improvement
in code quality; you'll be getting y-positions relative to each motion
event's window, which will not necessarily be the same as the original
mouse button event's window, or even the same from motion event to
motion event.
So how about a model where the modeline moves by 1 line after the
mouse moves a threshold number of vertical pixels?
that's what's happening now, in the line mentioned above when we
divide by default-line-height.
The threshold could be configurable to the user's taste, or it
could
be a fraction of the line height. The main problem with this approach
is that for a multiple line drag, the pointer would slip off the
modeline, which might feel odd.
again that's how it works today.
Greg
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta