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

[Aaron Jensen <aaronjensen@gmail.com>]

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

> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sun, 27 May 2018 10:13:55 -0700
> > Cc: martin rudalics <rudalics@gmx.at>, Alan Third <alan@idiocy.org>,
31546@debbugs.gnu.org
> >
> > On Sun, May 27, 2018 at 8:58 AM Eli Zaretskii <eliz@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.