GNU bug report logs - #31546
27.0.50; macOS child frames with no mode-line mouse click problem

Previous Next

Full log

View this message in rfc822 format

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31546 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>, Alan Third <alan <at> idiocy.org>
Subject: bug#31546: 27.0.50; macOS child frames with no mode-line mouse click problem
Date: Sun, 27 May 2018 10:52:39 -0700

On Sun, May 27, 2018 at 10:39 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Aaron Jensen <aaronjensen <at> gmail.com>
> > Date: Sun, 27 May 2018 10:13:55 -0700
> > Cc: martin rudalics <rudalics <at> gmx.at>, Alan Third <alan <at> idiocy.org>,
31546 <at> debbugs.gnu.org
> >
> > On Sun, May 27, 2018 at 8:58 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > Based on the description, I think it's redisplay that's scrolling,
> > > because the mouse click sets point in a line that is visible only
> > > partially.
> >
> > To be clear, this is only true if my patch is applied. If my patch is
not
> > applied, clicking on the last line of a frame that has no minibuffer
and no
> > mode-line also triggers the scroll as well because the fact that it has
no
> > mode-line is not taken into account.

> Not sure I understand the connection between not having a mode line
> and the scroll.  Can you elaborate?  Apologies if this was already
> explained up-thread.

I'm not sure I can explain the actual mechanism as to why it matters, but
I'll explain what I can see.
In mouse-drag-track, the bottom of the window is calculated:

(bottom (if (window-minibuffer-p start-window)
      (nth 3 bounds)
    ;; Don't count the mode line.
    (1- (nth 3 bounds))))

I'm guessing this is somehow used to determine whether or not to scroll the
clicked location into view. The calculation is wrong if there is no
mode-line because it subtracts 1 unnecessarily. My patch adds to the
condition a check for the mode line format and does not subtract 1 if that
is nil.

Actually, looking at the code that's exactly what's happening:

(cond
                   ((null mouse-row))
                   ((< mouse-row top)
                    (mouse-scroll-subr start-window (- mouse-row top)
                                       nil start-point))
                   ((>= mouse-row bottom)
                    (mouse-scroll-subr start-window (1+ (- mouse-row bottom))
                                       nil start-point)))

If the location clicked is >= to the bottom (which is miscalculated without
my patch when there is no mode-line and it is >= in the case of a partial
line visibility) then the window is scrolled, explicitly. So, that's the
problem afaict.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.