Subject: bug#76691: `display-monitor-attributes-list` not working properly on macOS

From: Ruiyang Wu <[email-masked]>
Date: Tue, 4 Mar 2025 22:52:34 -0500

Hi Stephane,

I have tested your patch on master, and it worked very well on both directions, including the `make-frame-on-monitor` function. I cannot reproduce the crash that Robert reported.

I have tested plugging and unplugging the external monitor. The output of `x-display-list` stays unchanged as the hostname, whereas the output of `display-monitor-attributes-list` updates to reflect the new monitor configurations. So things are looking good on my end.

Best,
Ruiyang

> On Mar 4, 2025, at 12:34 PM, Ship Mints <[email-masked]> wrote:
> 
> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <[email-masked] <mailto:[email-masked]>> wrote:
>> >>>>> On Tue, 4 Mar 2025 09:58:13 -0500, Ship Mints <[email-masked] <mailto:[email-masked]>> said:
>>     Ship> And a synthesized name: (((name . "3200x1775@0,25") (geometry 0 0 3200
>>     Ship> 1800) (workarea 0 25 3200 1775) (mm-size 599 339) (frames #<frame *scratch*
>>     0x7f7c7009d430> ) (source . "NS")))
>> 
>>     Ship> We could use something like a UUID that's more opaque.
>> 
>>     Ship> I haven't made either name bi-directional yet to allow specifying it when
>>     Ship> operating on frames.
>> 
>> Yes, emacs crashes when I run `make-frame-on-monitor' :-)
> 
> Does Emacs work when you run make-frame-on-current-monitor starting from a selected frame on a secondary monitor?  make-frame-on-current-monitor does not depend on monitor names.  It would give me a hint where to look.  Even make-frame-on-monitor uses a monitor name only to get the geometry at which to place the new frame so if -current-monitor works but not named, it'll be interesting.