bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#31546: 27.0.50; macOS child frames with no mode-line mouse click problem
Date: Sun, 27 May 2018 20:38:53 +0300

> From: Aaron Jensen <address@hidden>
> Date: Sun, 27 May 2018 10:13:55 -0700
> Cc: martin rudalics <address@hidden>, Alan Third <address@hidden>, 
> address@hidden
> 
> On Sun, May 27, 2018 at 8:58 AM Eli Zaretskii <address@hidden> 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.

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

"Doesn't move there" and "can be set there" sounds like a
contradiction, doesn't it?  I'm probably missing something because I
don't understand what you describe.  Clicking on the empty area beyond
the last buffer position should move point to EOB, but you seem to be
talking about something else?

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

You need to build with --enable-checking='yes,glyphs' to have that
command compiled into Emacs.  It's on xdisp.c, so it should be
available on all builds.

I usually find its output helpful because it provides hints for where
to look for relevant code.  Of course, if the problem is in NS
specific code, we won't see anything interesting in the trace.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]