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:13:55 -0700

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.

Also, why is it that the point can be set to a location past the buffer's
end? The point won't actually move there visually, so I'm not sure why it
can be set there.

> One can make sure by invoking trace-redisplay before
> clicking (but make sure you have blink-cursor-mode and
> global-eldoc-mode turned off before you do that, to avoid unnecessary
> redisplay cycles that will muddy the waters).

trace-redisplay is only in x, it doesn't appear to be defined in ns. That
said, it could be redisplay that is scrolling it, but it seems that it's
due to something that mouse-drag-track is doing. There's a lot going on in
there that I do not understand, so it's hard for me to track down. Using
edebug on it doesn't seem to help much either because I keep getting
trapped in the mouse-movement lambda.

Could it have something to do with the mouse drag code getting confused
because the window is never selected?

Previous Next

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