Subject: bug#9366: Display geometry change hook

From: Eli Zaretskii <[email-masked]>
Date: Tue, 22 Sep 2020 17:16:58 +0300

> Cc: [email-masked], [email-masked], [email-masked]
> From: martin rudalics <[email-masked]>
> Date: Tue, 22 Sep 2020 09:16:58 +0200
> 
>  > Yes, I know about WM_DISPLAYCHANGE (although we currently only handle
>  > the full-screen frames there).
> 
> Has anyone ever confirmed that it correctly handles the full-screen
> frames?

I don't know.  I don't have a system to try that.

>  > But the corresponding X feature
>  > requires the use of a special X module, and I don't know what happens
>  > on macOS.  So I thought a platform-independent method that always
>  > works, and can be implemented in just one place, is a better
>  > alternative.
> 
> But such a platform-independent method on X would boil down to using the
> same special X module as the platform-dependent method.  That is, we
> would try running XRANDR in either case ...

Do we use XRANDR to query the display geometry?

>  > Besides, adding one more special event comes with minor disadvantages
>  > of its own -- one more event to disregard in situations like
>  > while-no-input etc.
> 
> But at least on Windows we have to pay attention to such events anyway.

I didn't mean MS-Windows events (a.k.a. "messages"), I meant events in
the Emacs event queue.  A message coming from the window manager
doesn't have to be converted to an Emacs event, it can be handled
directly.