[Top][All Lists]

[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: martin rudalics
Subject: bug#31546: 27.0.50; macOS child frames with no mode-line mouse click problem
Date: Thu, 24 May 2018 09:19:44 +0200

>> Now I am confused.  Is this in any way related to the OP's report?
>> There the window below in the z-order gets scrolled but here you seem
>> to mean that a mouse click affects the window above in the z-order.
> I'm the OP. I'm sorry if I wasn't clear in the initial report. The problem
> is that the child frame (which appears on top of the parent frame) gets
> scrolled on click. In this gif, the visible frame is the child frame:

But I referred to Alan's response and it seems that he sees the
converse of what you observed.

>> I still don't understand which command gets executed in order to
>> scroll the parent frame's window.  That is, if with emacs -Q I click
>> anywhere on my single frame's only window's mode line, that window
>> never scrolls.  So please tell me how your window gets scrolled.
> I do not know what the command is that is scrolling the child frame. It
> does not appear in view-lossage.

And C-h k does not give any clue either?  Try putting "(ding)" into
'mouse-set-point' just before "(mouse-minibuffer-check)" and check
whether it rings when you click.  If it does, then please look into
'posn-set-point' which window gets selected.  I suppose it's the
parent frame's window which gets passed via EVENT to 'mouse-set-point'
so we will have to check why the child frame's window is not found
when constructing the event.  The corresponding GTK code to get the
right frame is already quite painful (see 'XTmouse_position') so I
wouldn't be surprised if macOS had similar problems.

>> If "the frame" is a child frame then this problem is pertinent to your
>> windowing system: With X or Windows child frames cannot be moved out
>> of their parent frames.
> This may be, but I'm at a loss as to how my windowing system would increase
> the height of an emacs window. It seems more likely that it is due to some
> bug in nsterm, but I have been wrong before.

Sorry.  I referred to your earlier

  I should say that even if I move the frame so that it's not over the parent
  frame the scrolling bug still happens.

so this was about moving the frame and not changing its height.


reply via email to

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