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

From: Ship Mints <[email-masked]>
Date: Wed, 5 Mar 2025 06:38:05 -0500

On Wed, Mar 5, 2025 at 4:04 AM Robert Pluim <[email-masked]> wrote:

> >>>>> On Tue, 4 Mar 2025 11:06:29 -0500, Ship Mints <[email-masked]>
> said:
>
>     Ship> On Tue, Mar 4, 2025 at 10:59 AM Ship Mints <[email-masked]>
> wrote:
>     >> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <[email-masked]>
> wrote:
>     >>
>     >>> It gives me reasonable looking names here:
>     >>>
>     >>> (((name . "PL3467WQ") (geometry 0 0 3440 1440) (workarea 0 25 3440
>     >>> 1415) (mm-size 801 329) (frames #<frame *scratch* 0x131887028>)
>     >>> (source . "NS")) ((name . "Built-in Display") (geometry 459 1440
> 2048
>     >>> 1332) (workarea 459 1440 2048 1287) (mm-size 290 189) (frames)
> (source
>     >>> . "NS")))
>     >>>
>     >>
>     >> Robert,
>     >>
>     >> When you run (x-display-list), what do you get? Just your host name,
>     >> right? And if you unplug and replug your monitors and rerun?
>     >>
>
> I get just my host name.
>
>     Ship> And also (display-monitor-attributes-list) just to make sure it
> works with
>     Ship> comings and goings of displays.
>
> I unplugged and replugged my external monitor, and Emacs crashed in
> `read_char', which is a different crash from the one I saw earlier,
> which was in `Fx_create_frame'. Iʼve got the lldb session if it helps.
>

The way make-frame-on-monitor is implemented is nothing special.  Just find
the coordinates of the "workspace" occupied by the named monitor and use
those as the basis for the new frame.  The bt from yesterday's perhaps
indicates some kind of guard might be needed for frame coordinates that
might be out of bounds, perhaps?  Do you think the frame on the second
monitor was larger than the screen?  I admit to not having played much with
trying to make oversized frames but it happens to me occasionally if only
over left and right by a column or row or two, not more.

I'm curious what the read_char bt looks like.  You saw the patch, it's
pretty much a nothing.  I updated it yesterday to use xstrdup instead of
the two-step.  I doubt that's anything.  But here's the updated patch, just
in case.