>>>>> On Tue, 4 Mar 2025 11:06:29 -0500, Ship Mints <shipmints@gmail.com> said:
Ship> On Tue, Mar 4, 2025 at 10:59 AM Ship Mints <shipmints@gmail.com> wrote:
>> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim@gmail.com> 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.