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 <shipmints@gmail.com> wrote:

On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim@gmail.com> wrote:
>>>>> On Tue, 4 Mar 2025 09:58:13 -0500, Ship Mints <shipmints@gmail.com> 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.