GNU bug report logs -
#76691
`display-monitor-attributes-list` not working properly on macOS
Previous Next
Reported by: Ruiyang Wu <ywwry66 <at> gmail.com>
Date: Sun, 2 Mar 2025 21:00:03 UTC
Severity: normal
Tags: confirmed, patch
Merged with 76051
Found in versions 29.4, 30.1, 31.0.50
Done: Alan Third <alan <at> idiocy.org>
To reply to this bug, email your comments to 76691 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Sun, 02 Mar 2025 21:00:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ruiyang Wu <ywwry66 <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 02 Mar 2025 21:00:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I am using the official NS port Emacs 30.1 on a MacBook (macOS Sequoia) with an external monitor. The output of `display-monitor-attributes-list` is as follows:
> (((geometry 0 0 1512 982) (workarea 0 38 1512 944) (mm-size 301 195) (frames) (source . "NS")) ((geometry 1512 -517 1600 900 (workarea 1512 -517 1600 875) (mm-size 549 311) (frames #<frame scratch* 0x12d08e430>) (source . "NS")))
It fails to recognize my monitors. Furthermore, when I run `M-x make-frame-on-monitor`, no candidate is provided.
However, if I use `emacs-mac` from https://bitbucket.org/mituharu/emacs-mac/src/master/, the monitors can be correctly recognized. `display-monitor-attributes-list` prints
> (((geometry 0 0 1512 982) (workarea 0 38 1512 944) (mm-size 301 196) (frames) (name . "Built-in Retina Display") (backing-scale-factor . 2)) ((geometry 1512 -517 1600 900) (workarea 1512 -492 1600 875) (mm-size 549 311) (frames #<frame *scratch* - GNU Emacs at Ruiyangs-MBP 0x1400a62c8>) (name . "DELL U2515H") (backing-scale-factor . 2)))
And I can also use `make-frame-on-monitor` to create new frames without issue.
Is it possible to have the aforementioned behavior from `emacs-mac` in the official NS port? That would greatly improve my workflow. Thank you very much!
Best,
Ruiyang
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Sun, 02 Mar 2025 21:13:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
If you try the following Emacs 30.1 NS build and it works for you, I think
I know which one-liner patch might need to be applied to make this work. I
don't have more than one monitor so I can't easily test this on my own. If
I submit a patch for this, would you be able to build from master? I could
try to use my iPad as an external monitor, I suppose but not sure if that
will work.
https://github.com/jimeh/emacs-builds/releases/tag/Emacs-30.1
On Sun, Mar 2, 2025 at 4:00 PM Ruiyang Wu <ywwry66 <at> gmail.com> wrote:
> Hi,
>
> I am using the official NS port Emacs 30.1 on a MacBook (macOS Sequoia)
> with an external monitor. The output of `display-monitor-attributes-list`
> is as follows:
>
> (((geometry 0 0 1512 982) (workarea 0 38 1512 944) (mm-size 301 195)
> (frames) (source . "NS")) ((geometry 1512 -517 1600 900 (workarea 1512 -517
> 1600 875) (mm-size 549 311) (frames #<frame scratch* 0x12d08e430>) (source
> . "NS")))
>
> It fails to recognize my monitors. Furthermore, when I run `M-x
> make-frame-on-monitor`, no candidate is provided.
>
>
> However, if I use `emacs-mac` from
> https://bitbucket.org/mituharu/emacs-mac/src/master/, the monitors can be
> correctly recognized. `display-monitor-attributes-list` prints
>
> (((geometry 0 0 1512 982) (workarea 0 38 1512 944) (mm-size 301 196)
> (frames) (name . "Built-in Retina Display") (backing-scale-factor . 2))
> ((geometry 1512 -517 1600 900) (workarea 1512 -492 1600 875) (mm-size 549
> 311) (frames #<frame *scratch* - GNU Emacs at Ruiyangs-MBP 0x1400a62c8>)
> (name . "DELL U2515H") (backing-scale-factor . 2)))
>
> And I can also use `make-frame-on-monitor` to create new frames without
> issue.
>
>
> Is it possible to have the aforementioned behavior from `emacs-mac` in
> the official NS port? That would greatly improve my workflow. Thank you
> very much!
>
>
> Best,
> Ruiyang
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Mon, 03 Mar 2025 02:30:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for the suggestion. I tried both the stable release and the nightly build from the repo you linked, but unfortunately they seem to behave the same way as the official NS port. If you are able to come up with a patch, I would definitely like to test that on the master branch.
Best,
Ruiyang
> On Mar 2, 2025, at 4:12 PM, Ship Mints <shipmints <at> gmail.com> wrote:
>
> If you try the following Emacs 30.1 NS build and it works for you, I think I know which one-liner patch might need to be applied to make this work. I don't have more than one monitor so I can't easily test this on my own. If I submit a patch for this, would you be able to build from master? I could try to use my iPad as an external monitor, I suppose but not sure if that will work.
>
> https://github.com/jimeh/emacs-builds/releases/tag/Emacs-30.1
>
> On Sun, Mar 2, 2025 at 4:00 PM Ruiyang Wu <ywwry66 <at> gmail.com <mailto:ywwry66 <at> gmail.com>> wrote:
>> Hi,
>>
>> I am using the official NS port Emacs 30.1 on a MacBook (macOS Sequoia) with an external monitor. The output of `display-monitor-attributes-list` is as follows:
>>> (((geometry 0 0 1512 982) (workarea 0 38 1512 944) (mm-size 301 195) (frames) (source . "NS")) ((geometry 1512 -517 1600 900 (workarea 1512 -517 1600 875) (mm-size 549 311) (frames #<frame scratch* 0x12d08e430>) (source . "NS")))
>> It fails to recognize my monitors. Furthermore, when I run `M-x make-frame-on-monitor`, no candidate is provided.
>>
>>
>> However, if I use `emacs-mac` from https://bitbucket.org/mituharu/emacs-mac/src/master/, the monitors can be correctly recognized. `display-monitor-attributes-list` prints
>>> (((geometry 0 0 1512 982) (workarea 0 38 1512 944) (mm-size 301 196) (frames) (name . "Built-in Retina Display") (backing-scale-factor . 2)) ((geometry 1512 -517 1600 900) (workarea 1512 -492 1600 875) (mm-size 549 311) (frames #<frame *scratch* - GNU Emacs at Ruiyangs-MBP 0x1400a62c8>) (name . "DELL U2515H") (backing-scale-factor . 2)))
>> And I can also use `make-frame-on-monitor` to create new frames without issue.
>>
>>
>> Is it possible to have the aforementioned behavior from `emacs-mac` in the official NS port? That would greatly improve my workflow. Thank you very much!
>>
>> Best,
>> Ruiyang
>>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Mon, 03 Mar 2025 19:57:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 76691 <at> debbugs.gnu.org (full text, mbox):
found 76691 30.1
found 76691 31.0.50
tags 76691 + confirmed
thanks
Ruiyang Wu <ywwry66 <at> gmail.com> writes:
> I am using the official NS port Emacs 30.1 on a MacBook (macOS Sequoia) with an external monitor. The output of `display-monitor-attributes-list` is as follows:
>> (((geometry 0 0 1512 982) (workarea 0 38 1512 944) (mm-size 301 195) (frames) (source . "NS")) ((geometry 1512 -517 1600 900 (workarea 1512 -517 1600 875) (mm-size 549 311) (frames #<frame scratch* 0x12d08e430>) (source . "NS")))
> It fails to recognize my monitors. Furthermore, when I run `M-x make-frame-on-monitor`, no candidate is provided.
>
> However, if I use `emacs-mac` from https://bitbucket.org/mituharu/emacs-mac/src/master/, the monitors can be correctly recognized. `display-monitor-attributes-list` prints
>> (((geometry 0 0 1512 982) (workarea 0 38 1512 944) (mm-size 301 196) (frames) (name . "Built-in Retina Display") (backing-scale-factor . 2)) ((geometry 1512 -517 1600 900) (workarea 1512 -492 1600 875) (mm-size 549 311) (frames #<frame *scratch* - GNU Emacs at Ruiyangs-MBP 0x1400a62c8>) (name . "DELL U2515H") (backing-scale-factor . 2)))
> And I can also use `make-frame-on-monitor` to create new frames without issue.
>
> Is it possible to have the aforementioned behavior from `emacs-mac` in the official NS port? That would greatly improve my workflow. Thank you very much!
I can reproduce this on current master, in other words,
M-x make-frame-on-monitor RET
doesn't provide any completion candidates.
In `make-frame-on-monitor`, I see that this
(mapcar (lambda (a)
(cdr (assq 'name a)))
(display-monitor-attributes-list))
produces this on both macOS and GNU/Linux:
(nil nil)
So I guess this is not specific to the NS port?
Juri, since you added this command, WDYT?
bug Marked as found in versions 30.1.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 03 Mar 2025 19:57:02 GMT)
Full text and
rfc822 format available.
bug Marked as found in versions 31.0.50.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 03 Mar 2025 19:57:02 GMT)
Full text and
rfc822 format available.
Added tag(s) confirmed.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 03 Mar 2025 19:57:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Mon, 03 Mar 2025 20:06:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Mar 3, 2025 at 2:58 PM Stefan Kangas <stefankangas <at> gmail.com> wrote:
> found 76691 30.1
> found 76691 31.0.50
> tags 76691 + confirmed
> thanks
>
> Ruiyang Wu <ywwry66 <at> gmail.com> writes:
>
> > I am using the official NS port Emacs 30.1 on a MacBook (macOS Sequoia)
> with an external monitor. The output of `display-monitor-attributes-list`
> is as follows:
> >> (((geometry 0 0 1512 982) (workarea 0 38 1512 944) (mm-size 301 195)
> (frames) (source . "NS")) ((geometry 1512 -517 1600 900 (workarea 1512 -517
> 1600 875) (mm-size 549 311) (frames #<frame scratch* 0x12d08e430>) (source
> . "NS")))
> > It fails to recognize my monitors. Furthermore, when I run `M-x
> make-frame-on-monitor`, no candidate is provided.
> >
> > However, if I use `emacs-mac` from
> https://bitbucket.org/mituharu/emacs-mac/src/master/, the monitors can be
> correctly recognized. `display-monitor-attributes-list` prints
> >> (((geometry 0 0 1512 982) (workarea 0 38 1512 944) (mm-size 301 196)
> (frames) (name . "Built-in Retina Display") (backing-scale-factor . 2))
> ((geometry 1512 -517 1600 900) (workarea 1512 -492 1600 875) (mm-size 549
> 311) (frames #<frame *scratch* - GNU Emacs at Ruiyangs-MBP 0x1400a62c8>)
> (name . "DELL U2515H") (backing-scale-factor . 2)))
> > And I can also use `make-frame-on-monitor` to create new frames without
> issue.
> >
> > Is it possible to have the aforementioned behavior from `emacs-mac` in
> the official NS port? That would greatly improve my workflow. Thank you
> very much!
>
> I can reproduce this on current master, in other words,
>
> M-x make-frame-on-monitor RET
>
> doesn't provide any completion candidates.
>
> In `make-frame-on-monitor`, I see that this
>
> (mapcar (lambda (a)
> (cdr (assq 'name a)))
> (display-monitor-attributes-list))
>
> produces this on both macOS and GNU/Linux:
>
> (nil nil)
>
> So I guess this is not specific to the NS port?
>
> Juri, since you added this command, WDYT?
>
On my iMac and laptop, it works. I have some functions that depend on this
so I know it works.
(display-monitor-attributes-list)
(((geometry 0 0 3200 1800) (workarea 0 25 3200 1775) (mm-size 599 339)
(frames #<frame 30.1 0x7fd3322fbc70> #<frame 0x7fd2f3059610> #<frame
0x7fd33308a968>) (source . "NS")))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 07:14:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 76691 <at> debbugs.gnu.org (full text, mbox):
> I can reproduce this on current master, in other words,
>
> M-x make-frame-on-monitor RET
>
> doesn't provide any completion candidates.
>
> In `make-frame-on-monitor`, I see that this
>
> (mapcar (lambda (a)
> (cdr (assq 'name a)))
> (display-monitor-attributes-list))
>
> produces this on both macOS and GNU/Linux:
>
> (nil nil)
>
> So I guess this is not specific to the NS port?
>
> Juri, since you added this command, WDYT?
The command just uses the output of `display-monitor-attributes-list`.
I don't know why `display-monitor-attributes-list` doesn't recognize
monitors on macOS and doesn't return their 'name'. I tried
(mapcar (lambda (a)
(cdr (assq 'name a)))
(display-monitor-attributes-list))
and on GNU/Linux it correctly returns
("HDMI-1" "eDP-1")
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 11:01:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 2:14 AM Juri Linkov <juri <at> linkov.net> wrote:
> > I can reproduce this on current master, in other words,
> >
> > M-x make-frame-on-monitor RET
> >
> > doesn't provide any completion candidates.
> >
> > In `make-frame-on-monitor`, I see that this
> >
> > (mapcar (lambda (a)
> > (cdr (assq 'name a)))
> > (display-monitor-attributes-list))
> >
> > produces this on both macOS and GNU/Linux:
> >
> > (nil nil)
> >
> > So I guess this is not specific to the NS port?
> >
> > Juri, since you added this command, WDYT?
>
> The command just uses the output of `display-monitor-attributes-list`.
> I don't know why `display-monitor-attributes-list` doesn't recognize
> monitors on macOS and doesn't return their 'name'. I tried
>
> (mapcar (lambda (a)
> (cdr (assq 'name a)))
> (display-monitor-attributes-list))
>
> and on GNU/Linux it correctly returns
>
> ("HDMI-1" "eDP-1")
>
I'll try to dig into this a little more this week. d-m-a-l "works" for me
but doesn't have a monitor name. Perhaps it names them only when there's
more than one. I'll look in Apple's docs also.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 13:19:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 04 Mar 2025 09:10:19 +0200, Juri Linkov <juri <at> linkov.net> said:
Juri> The command just uses the output of `display-monitor-attributes-list`.
Juri> I don't know why `display-monitor-attributes-list` doesn't recognize
Juri> monitors on macOS and doesn't return their 'name'. I tried
Juri> (mapcar (lambda (a)
Juri> (cdr (assq 'name a)))
Juri> (display-monitor-attributes-list))
Juri> and on GNU/Linux it correctly returns
Juri> ("HDMI-1" "eDP-1")
See also bug#34516, which has a patch from me to invent monitor names
on macOS.
That bug also points at code from <https://github.com/glfw/glfw>,
which someone motivated could perhaps copy.
<https://github.com/glfw/glfw/blob/master/LICENSE.md> is as follows:
Copyright (c) 2002-2006 Marcus Geelnard
Copyright (c) 2006-2019 Camilla Löwy
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
The origin of this software must not be misrepresented; you must
not claim that you wrote the original software. If you use this
software in a product, an acknowledgment in the product
documentation would be appreciated but is not required.
Altered source versions must be plainly marked as such, and must
not be misrepresented as being the original software.
This notice may not be removed or altered from any source
distribution.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 13:24:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 8:19 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>
> See also bug#34516, which has a patch from me to invent monitor names
> on macOS.
>
> That bug also points at code from <https://github.com/glfw/glfw>,
> which someone motivated could perhaps copy.
>
Good idea, but they use IODisplayConnect which, sadly, is not supported on
Apple Silicon so we'll have to come up with a solution that works for both
Intel and M.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 13:27:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 8:23 AM Ship Mints <shipmints <at> gmail.com> wrote:
> On Tue, Mar 4, 2025 at 8:19 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>
>>
>> See also bug#34516, which has a patch from me to invent monitor names
>> on macOS.
>>
>> That bug also points at code from <https://github.com/glfw/glfw>,
>> which someone motivated could perhaps copy.
>>
>
> Good idea, but they use IODisplayConnect which, sadly, is not supported on
> Apple Silicon so we'll have to come up with a solution that works for both
> Intel and M.
>
I do see a reference in their code to NSScreen localizedName so maybe that
still works. I'll experiment with that.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 14:29:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here's what I get from localizedName on my iMac:
(((name . "Built-in Retina Display") (geometry 0 0 3200 1800) (workarea 0
25 3200 1775) (mm-size 599 339) (frames #<frame *scratch* 0x7fe165871c30>)
(source . "NS")))
Seems a bit cumbersome, but that's what it is. I can synthesize a name for
if this ever returns NULL; e.g., the equivalent of (format "%dx%d@%d,%d"
width height x y) where x and y are the coordinates relative to the origin
reported by macOS (adjusted for being inverted, if I recall correctly).
On Tue, Mar 4, 2025 at 8:26 AM Ship Mints <shipmints <at> gmail.com> wrote:
> On Tue, Mar 4, 2025 at 8:23 AM Ship Mints <shipmints <at> gmail.com> wrote:
>
>> On Tue, Mar 4, 2025 at 8:19 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>>
>>>
>>> See also bug#34516, which has a patch from me to invent monitor names
>>> on macOS.
>>>
>>> That bug also points at code from <https://github.com/glfw/glfw>,
>>> which someone motivated could perhaps copy.
>>>
>>
>> Good idea, but they use IODisplayConnect which, sadly, is not
>> supported on Apple Silicon so we'll have to come up with a solution that
>> works for both Intel and M.
>>
>
> I do see a reference in their code to NSScreen localizedName so maybe that
> still works. I'll experiment with that.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 14:52:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 4 Mar 2025 09:28:33 -0500, Ship Mints <shipmints <at> gmail.com> said:
Ship> (((name . "Built-in Retina Display") (geometry 0 0 3200 1800) (workarea 0
Ship> 25 3200 1775) (mm-size 599 339) (frames #<frame *scratch*
0x7fe165871c30> ) (source . "NS")))
That matches what the "Displays" settings shows, no?
Ship> Seems a bit cumbersome, but that's what it is. I can synthesize a name
Ship> for if this ever returns NULL; e.g., the equivalent of (format
Ship> "%dx%d@%d,%d" width height x y) where x and y are the coordinates
Ship> relative to the origin reported by macOS (adjusted for being inverted, if
Ship> I recall correctly).
If you have a patch, I can test it with the various external monitors
I have.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 14:59:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 9:51 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Tue, 4 Mar 2025 09:28:33 -0500, Ship Mints <shipmints <at> gmail.com>
> said:
>
> Ship> (((name . "Built-in Retina Display") (geometry 0 0 3200 1800)
> (workarea 0
> Ship> 25 3200 1775) (mm-size 599 339) (frames #<frame *scratch*
> 0x7fe165871c30> ) (source . "NS")))
>
> That matches what the "Displays" settings shows, no?
>
> Ship> Seems a bit cumbersome, but that's what it is. I can synthesize
> a name
> Ship> for if this ever returns NULL; e.g., the equivalent of (format
> Ship> "%dx%d@%d,%d" width height x y) where x and y are the
> coordinates
> Ship> relative to the origin reported by macOS (adjusted for being
> inverted, if
> Ship> I recall correctly).
>
> If you have a patch, I can test it with the various external monitors
> I have.
>
And a synthesized name: (((name . "3200x1775 <at> 0,25") (geometry 0 0 3200
1800) (workarea 0 25 3200 1775) (mm-size 599 339) (frames #<frame *scratch*
0x7f7c7009d430>) (source . "NS")))
We could use something like a UUID that's more opaque.
I haven't made either name bi-directional yet to allow specifying it when
operating on frames.
Thanks for the help. Patch attached.
[Message part 2 (text/html, inline)]
[0001-Improve-NS-display-names-in-display-monitor-attribut.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 15:35:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 4 Mar 2025 09:58:13 -0500, Ship Mints <shipmints <at> gmail.com> said:
Ship> And a synthesized name: (((name . "3200x1775 <at> 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' :-)
Ship> Thanks for the help. Patch attached.
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")))
Ship> #ifdef NS_IMPL_COCOA
Ship> - m->name = ns_screen_name (did);
Ship> + m->name = NULL;
Ship> + if ([s respondsToSelector:@selector(localizedName)])
Ship> + {
Ship> + NSString *name = [s valueForKey:@"localizedName"];
Ship> + if (name != NULL)
Ship> + {
Ship> + m->name = xmalloc ([name lengthOfBytesUsingEncoding: NSUTF8StringEncoding]);
Ship> + strcpy(m->name, [name UTF8String]);
Ship> + }
Ship> + }
Ship> + /* If necessary, synthesize a name of the following form:
Ship> + %dx%d@%d,%d width height x y */
Ship> + if (m->name == NULL)
Ship> + {
Ship> + char buf[25]; /* sufficient for 12345x78901 <at> 34567,90123 */
Ship> + snprintf (buf, sizeof(buf), "%ux%u@%d,%d", m->work.width, m->work.height, m->work.x, m->work.y);
Ship> + m->name = xmalloc (strlen (buf));
Ship> + strcpy(m->name, buf);
Ship> + }
How many version back of macOS does localizedName work for?
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 15:40:03 GMT)
Full text and
rfc822 format available.
Message #53 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> How many version back of macOS does localizedName work for?
>
10.15. No worries for anyone using the platform these days, I think. Do
you think I should wrap it? Hrumph, if so. We need to modernize the NS
implementation at some point.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 15:43:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 4 Mar 2025 10:38:41 -0500, Ship Mints <shipmints <at> gmail.com> said:
Ship> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>> How many version back of macOS does localizedName work for?
>>
Ship> 10.15. No worries for anyone using the platform these days, I think. Do
Ship> you think I should wrap it? Hrumph, if so. We need to modernize the NS
Ship> implementation at some point.
I guess the functionality has been broken for quite some time now, so
getting it back should be enough (but Iʼm not an Emacs maintainter).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 15:46:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 10:42 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Tue, 4 Mar 2025 10:38:41 -0500, Ship Mints <shipmints <at> gmail.com>
> said:
>
> Ship> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> gmail.com>
> wrote:
> >> How many version back of macOS does localizedName work for?
> >>
>
> Ship> 10.15. No worries for anyone using the platform these days, I
> think. Do
> Ship> you think I should wrap it? Hrumph, if so. We need to
> modernize the NS
> Ship> implementation at some point.
>
> I guess the functionality has been broken for quite some time now, so
> getting it back should be enough (but Iʼm not an Emacs maintainter).
>
Now, it's just "work" to make it bidi. I'll try to spend time on it this
week.
Wu Ruiyang, are you okay using the reported names that you've seen in this
thread or the synthesized names? I assume you're not hard coding
references to display names?
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 15:59:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thank you Stephane for the investigation. The outputs that you and Robert attached look good to me. I will also test the patch myself later today or tomorrow.
Stefan earlier mentioned that the issue may also exist on some GNU/Linux platforms. I wonder if that also needs to be addressed in this bug report.
Best,
Ruiyang
> On Mar 4, 2025, at 10:45 AM, Ship Mints <shipmints <at> gmail.com> wrote:
>
> On Tue, Mar 4, 2025 at 10:42 AM Robert Pluim <rpluim <at> gmail.com <mailto:rpluim <at> gmail.com>> wrote:
>> >>>>> On Tue, 4 Mar 2025 10:38:41 -0500, Ship Mints <shipmints <at> gmail.com <mailto:shipmints <at> gmail.com>> said:
>>
>> Ship> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> gmail.com <mailto:rpluim <at> gmail.com>> wrote:
>> >> How many version back of macOS does localizedName work for?
>> >>
>>
>> Ship> 10.15. No worries for anyone using the platform these days, I think. Do
>> Ship> you think I should wrap it? Hrumph, if so. We need to modernize the NS
>> Ship> implementation at some point.
>>
>> I guess the functionality has been broken for quite some time now, so
>> getting it back should be enough (but Iʼm not an Emacs maintainter).
>
> Now, it's just "work" to make it bidi. I'll try to spend time on it this week.
>
> Wu Ruiyang, are you okay using the reported names that you've seen in this thread or the synthesized names? I assume you're not hard coding references to display names?
>
> -Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 16:00:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> 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?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 16:01:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 10:58 AM Ruiyang Wu <ywwry66 <at> gmail.com> wrote:
> Thank you Stephane for the investigation. The outputs that you and Robert
> attached look good to me. I will also test the patch myself later today or
> tomorrow.
>
> Stefan earlier mentioned that the issue may also exist on some GNU/Linux
> platforms. I wonder if that also needs to be addressed in this bug report.
>
Those would be separate bug reports. I do not think there is any shared
code involved across platform display engines.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 16:07:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 10:59 AM Ship Mints <shipmints <at> gmail.com> wrote:
> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> 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?
>
And also (display-monitor-attributes-list) just to make sure it works with
comings and goings of displays.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 16:35:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 11:06 AM Ship Mints <shipmints <at> gmail.com> wrote:
> On Tue, Mar 4, 2025 at 10:59 AM Ship Mints <shipmints <at> gmail.com> wrote:
>
>> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> 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?
>>
>
> And also (display-monitor-attributes-list) just to make sure it works with
> comings and goings of displays.
>
This thread from 2019 (Robert and Juri were there) seems to have hashed out
some of the monitor naming, both natural (reported), and synthetic. Being
able to restore multi-monitor framesets seems a good use case but I wonder
how many macOS users would really use it and how much we should fuss to
strive to make monitor names as static as possible. One issue would be
restoring a frameset with a different second or third monitor that reports
a different natural name, or with different smaller or larger geometry than
the record stored in the frameset. Maybe some sort of monitor aliases akin
to the DISPLAY1 DISPLAY2 idea but which would associate with whatever the
currently reported displays are in sequential order, where DISPLAY1 is
always the "main" display.
https://lists.gnu.org/r/bug-gnu-emacs/2019-02/msg00526.html
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Tue, 04 Mar 2025 17:35:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Tue, 4 Mar 2025 09:58:13 -0500, Ship Mints <shipmints <at> gmail.com>
> said:
> Ship> And a synthesized name: (((name . "3200x1775 <at> 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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 05 Mar 2025 03:53:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gmail.com> wrote:
>
> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> gmail.com <mailto:rpluim <at> gmail.com>> wrote:
>> >>>>> On Tue, 4 Mar 2025 09:58:13 -0500, Ship Mints <shipmints <at> gmail.com <mailto:shipmints <at> gmail.com>> said:
>> Ship> And a synthesized name: (((name . "3200x1775 <at> 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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 05 Mar 2025 08:54:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 4 Mar 2025 12:34:11 -0500, Ship Mints <shipmints <at> gmail.com> said:
>> Yes, emacs crashes when I run `make-frame-on-monitor' :-)
>>
Ship> Does Emacs work when you run make-frame-on-current-monitor starting from a
Ship> selected frame on a secondary monitor? make-frame-on-current-monitor does
Ship> not depend on monitor names. It would give me a hint where to look. Even
Ship> make-frame-on-monitor uses a monitor name only to get the geometry at which
Ship> to place the new frame so if -current-monitor works but not named, it'll be
Ship> interesting.
`make-frame-on-current-monitor' works fine. And of course now I canʼt
reproduce the crash after recompiling with "-O0 -g3", although today
Iʼm using a different monitor than yesterday. I can try the original
one again tomorrow. I do have a backtrace, but unfortunately donʼt
have that lldb session anymore.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00000001854e3720 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x000000018551bf70 libsystem_pthread.dylib`pthread_kill + 288
frame #2: 0x0000000185428908 libsystem_c.dylib`abort + 128
frame #3: 0x0000000185331e38 libsystem_malloc.dylib`malloc_vreport + 896
frame #4: 0x000000018535a458 libsystem_malloc.dylib`malloc_zone_error + 100
frame #5: 0x0000000185349774 libsystem_malloc.dylib`nanov2_guard_corruption_detected + 44
frame #6: 0x0000000185349734 libsystem_malloc.dylib`nanov2_allocate_outlined + 460
frame #7: 0x0000000185348468 libsystem_malloc.dylib`nanov2_calloc_type + 568
frame #8: 0x000000018514ba44 libobjc.A.dylib`class_createInstance + 72
frame #9: 0x000000018558b5a8 CoreFoundation`__CFAllocateObject + 20
frame #10: 0x000000018558b558 CoreFoundation`__NSSingleObjectArrayI_new + 48
frame #11: 0x00000001855adc78 CoreFoundation`-[NSArray initWithArray:range:copyItems:] + 368
frame #12: 0x0000000185605118 CoreFoundation`-[NSMutableArray sortedArrayFromRange:options:usingComparator:] + 64
frame #13: 0x000000018924efe0 AppKit`_distributeSpaceToItems + 872
frame #14: 0x00000001899a0664 AppKit`-[NSBarLayout _calculateLayoutOfItems:inRect:sharesLeadingEdge:sharesTrailingEdge:] + 1260
frame #15: 0x00000001899a013c AppKit`-[NSBarLayout _enumerateSectionsOfItems:usingBlock:] + 208
frame #16: 0x000000018999f900 AppKit`-[NSBarLayout _updateAttributesOfItems:inRect:] + 352
frame #17: 0x000000018999f5e4 AppKit`-[NSBarLayout layoutAttributesOfVisibleItems] + 312
frame #18: 0x0000000189243c18 AppKit`-[NSToolbarView _layoutDirtyItemViewersAndTileToolbar] + 2192
frame #19: 0x000000018925e360 AppKit`-[NSToolbarView layout] + 80
frame #20: 0x0000000189c67c7c AppKit`___NSViewLayout_block_invoke + 632
frame #21: 0x00000001891bc4d8 AppKit`NSPerformVisuallyAtomicChange + 108
frame #22: 0x00000001891c0dac AppKit`_NSViewLayout + 96
frame #23: 0x0000000189c5df20 AppKit`__36-[NSView _layoutSubtreeWithOldSize:]_block_invoke + 372
frame #24: 0x00000001891bc4d8 AppKit`NSPerformVisuallyAtomicChange + 108
frame #25: 0x00000001891c0d40 AppKit`-[NSView _layoutSubtreeWithOldSize:] + 100
frame #26: 0x0000000189c5e064 AppKit`__36-[NSView _layoutSubtreeWithOldSize:]_block_invoke + 696
frame #27: 0x00000001891bc4d8 AppKit`NSPerformVisuallyAtomicChange + 108
frame #28: 0x00000001891c0d40 AppKit`-[NSView _layoutSubtreeWithOldSize:] + 100
frame #29: 0x0000000189c5e064 AppKit`__36-[NSView _layoutSubtreeWithOldSize:]_block_invoke + 696
frame #30: 0x00000001891bc4d8 AppKit`NSPerformVisuallyAtomicChange + 108
frame #31: 0x00000001891c0d40 AppKit`-[NSView _layoutSubtreeWithOldSize:] + 100
frame #32: 0x0000000189c5e064 AppKit`__36-[NSView _layoutSubtreeWithOldSize:]_block_invoke + 696
frame #33: 0x00000001891bc4d8 AppKit`NSPerformVisuallyAtomicChange + 108
frame #34: 0x00000001891c0d40 AppKit`-[NSView _layoutSubtreeWithOldSize:] + 100
frame #35: 0x0000000189c5eb00 AppKit`__56-[NSView _layoutSubtreeIfNeededAndAllowTemporaryEngine:]_block_invoke + 908
frame #36: 0x00000001891bc4d8 AppKit`NSPerformVisuallyAtomicChange + 108
frame #37: 0x00000001891c0918 AppKit`-[NSView _layoutSubtreeIfNeededAndAllowTemporaryEngine:] + 100
frame #38: 0x00000001891bc4d8 AppKit`NSPerformVisuallyAtomicChange + 108
frame #39: 0x00000001891c08a8 AppKit`-[NSView layoutSubtreeIfNeeded] + 96
frame #40: 0x0000000189f463bc AppKit`-[NSWindow(NSConstraintBasedLayoutInternal) _layoutViewTree] + 104
frame #41: 0x00000001891be588 AppKit`-[NSWindow _oldPlaceWindow:fromServer:] + 540
frame #42: 0x00000001891bda34 AppKit`-[NSWindow _setFrameCommon:display:fromServer:] + 2032
frame #43: 0x0000000100207ab0 emacs`-[EmacsWindow setFrame:display:](self=<unavailable>, _cmd=<unavailable>, windowFrame=<unavailable>, displayViews=<unavailable>) at nsterm.m:9899:3 [opt]
frame #44: 0x0000000100207ae4 emacs`-[EmacsWindow setFrame:display:animate:](self=<unavailable>, _cmd=<unavailable>, windowFrame=<unavailable>, displayViews=<unavailable>, performAnimation=<unavailable>) at nsterm.m:9910:3 [opt]
frame #45: 0x0000000189259778 AppKit`-[NSThemeFrame _growWindowReshapeContentAndToolbarView:withOldToolbarFrameSize:animate:] + 976
frame #46: 0x00000001892591fc AppKit`-[NSThemeFrame _reshapeContentAndToolbarView:withOldToolbarFrameSize:resizeWindow:animate:] + 200
frame #47: 0x000000018924031c AppKit`-[NSThemeFrame _showHideToolbar:resizeWindow:animate:] + 156
frame #48: 0x0000000189232448 AppKit`-[NSWindow _showToolbar:animate:] + 140
frame #49: 0x000000018923234c AppKit`-[NSToolbar _show:animate:] + 96
frame #50: 0x00000001892322b4 AppKit`-[NSToolbar _toggleShown:animate:] + 92
frame #51: 0x000000018922ecd0 AppKit`-[NSWindow setToolbar:] + 384
frame #52: 0x00000001002069a4 emacs`-[EmacsWindow createToolbar:](self=0x000000011de10030, _cmd=<unavailable>, f=0x000000012e106de8) at nsterm.m:9383:3 [opt]
frame #53: 0x00000001002068b4 emacs`-[EmacsWindow initWithEmacsFrame:fullscreen:screen:](self=0x000000011de10030, _cmd=<unavailable>, f=0x000000012e106de8, fullscreen=<unavailable>, screen=<unavailable>) at nsterm.m:9350:7 [opt]
frame #54: 0x00000001002039c0 emacs`-[EmacsView initFrameFromEmacs:](self=0x000000011de0fc50, _cmd=<unavailable>, f=0x000000012e106de8) at nsterm.m:8089:3 [opt]
frame #55: 0x0000000100212f48 emacs`Fx_create_frame(parms=(struct Lisp_Cons *) $4 = 0x0000000120058560) at nsfns.m:1513:3 [opt]
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 05 Mar 2025 09:05:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 4 Mar 2025 11:06:29 -0500, Ship Mints <shipmints <at> gmail.com> said:
Ship> On Tue, Mar 4, 2025 at 10:59 AM Ship Mints <shipmints <at> gmail.com> wrote:
>> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> 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.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 05 Mar 2025 11:39:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Mar 5, 2025 at 4:04 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Tue, 4 Mar 2025 11:06:29 -0500, Ship Mints <shipmints <at> gmail.com>
> said:
>
> Ship> On Tue, Mar 4, 2025 at 10:59 AM Ship Mints <shipmints <at> gmail.com>
> wrote:
> >> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> 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.
[Message part 2 (text/html, inline)]
[0001-Improve-NS-display-names-in-display-monitor-attribut.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 05 Mar 2025 13:45:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 5 Mar 2025 06:38:05 -0500, Ship Mints <shipmints <at> gmail.com> said:
Ship> On Wed, Mar 5, 2025 at 4:04 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>> >>>>> On Tue, 4 Mar 2025 11:06:29 -0500, Ship Mints <shipmints <at> gmail.com>
>> said:
>>
Ship> On Tue, Mar 4, 2025 at 10:59 AM Ship Mints <shipmints <at> gmail.com>
>> wrote:
>> >> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> 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.
>>
Ship> The way make-frame-on-monitor is implemented is nothing special. Just find
Ship> the coordinates of the "workspace" occupied by the named monitor and use
Ship> those as the basis for the new frame. The bt from yesterday's perhaps
Ship> indicates some kind of guard might be needed for frame coordinates that
Ship> might be out of bounds, perhaps? Do you think the frame on the second
Ship> monitor was larger than the screen? I admit to not having played much with
Ship> trying to make oversized frames but it happens to me occasionally if only
Ship> over left and right by a column or row or two, not more.
The default frame size is smaller than both monitors. I guess itʼs
possible something decided to place it off screen.
Ship> I'm curious what the read_char bt looks like. You saw the patch, it's
Ship> pretty much a nothing. I updated it yesterday to use xstrdup instead of
Ship> the two-step. I doubt that's anything. But here's the updated patch, just
Ship> in case.
It might be an existing emacs issue, rather than anything to do with
your patch (if youʼre feeling inspired, rewriting the socket handling
on macOS to use the normal event loop rather than the hackery with a
separate thread to run select might improve the port a lot. Or it might
make no difference)
Anyway, Iʼm suspicious about the fact that `ns_read_socket' appears in
this backtrace twice.
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00000001854e3720 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x000000018551bf70 libsystem_pthread.dylib`pthread_kill + 288
frame #2: 0x0000000185428908 libsystem_c.dylib`abort + 128
frame #3: 0x0000000185331e38 libsystem_malloc.dylib`malloc_vreport + 896
frame #4: 0x000000018535a458 libsystem_malloc.dylib`malloc_zone_error + 100
frame #5: 0x0000000185349774 libsystem_malloc.dylib`nanov2_guard_corruption_detected + 44
frame #6: 0x0000000185349734 libsystem_malloc.dylib`nanov2_allocate_outlined + 460
frame #7: 0x0000000185348468 libsystem_malloc.dylib`nanov2_calloc_type + 568
frame #8: 0x000000018b69c610 CoreGraphics`CGGStackCreateWithGState + 40
frame #9: 0x000000018b71b0b0 CoreGraphics`CGDisplayListDrawInContextDelegate + 596
frame #10: 0x0000000189590ee4 AppKit`___lldb_unnamed_symbol169773 + 884
frame #11: 0x0000000189609008 AppKit`___lldb_unnamed_symbol172077 + 100
frame #12: 0x000000018e165fbc QuartzCore`CABackingStoreUpdate_ + 284
frame #13: 0x000000018e1bc2d8 QuartzCore`invocation function for block in CA::Layer::display_() + 120
frame #14: 0x000000018e16503c QuartzCore`-[CALayer _display] + 1636
frame #15: 0x0000000189608e94 AppKit`___lldb_unnamed_symbol172075 + 1372
frame #16: 0x00000001896096b0 AppKit`___lldb_unnamed_symbol172087 + 28
frame #17: 0x00000001894fc49c AppKit`___lldb_unnamed_symbol166799 + 148
frame #18: 0x0000000189608f88 AppKit`___lldb_unnamed_symbol172076 + 128
frame #19: 0x000000018e1641b8 QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 784
frame #20: 0x000000018e2f30e4 QuartzCore`CA::Context::commit_transaction(CA::Transaction*, double, double*) + 528
frame #21: 0x000000018e146780 QuartzCore`CA::Transaction::commit() + 648
frame #22: 0x000000018929da9c AppKit`__62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 272
frame #23: 0x0000000189ca88f4 AppKit`___NSRunLoopObserverCreateWithHandler_block_invoke + 64
frame #24: 0x0000000185603be8 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36
frame #25: 0x0000000185603ad4 CoreFoundation`__CFRunLoopDoObservers + 552
frame #26: 0x0000000185603104 CoreFoundation`__CFRunLoopRun + 788
frame #27: 0x0000000185602734 CoreFoundation`CFRunLoopRunSpecific + 588
frame #28: 0x0000000190b71530 HIToolbox`RunCurrentEventLoopInMode + 292
frame #29: 0x0000000190b7717c HIToolbox`ReceiveNextEventCommon + 216
frame #30: 0x0000000190b77508 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76
frame #31: 0x000000018917a848 AppKit`_DPSNextEvent + 660
frame #32: 0x0000000189ae0c24 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
frame #33: 0x000000018916d874 AppKit`-[NSApplication run] + 480
frame #34: 0x00000001001fbf44 emacs`-[EmacsApp run](self=0x0000000129722680, _cmd=<unavailable>) at nsterm.m:5938:7 [opt]
frame #35: 0x000000010020efb0 emacs`ns_read_socket_1(terminal=<unavailable>, hold_quit=<unavailable>, no_release=<unavailable>) at nsterm.m:4812:11 [opt]
frame #36: 0x00000001000dc838 emacs`gobble_input at keyboard.c:7919:17 [opt]
frame #37: 0x00000001000d8d80 emacs`swallow_events [inlined] get_input_pending(flags=1) at keyboard.c:7875:7 [opt]
frame #38: 0x00000001000d8d0c emacs`swallow_events(do_display=true) at keyboard.c:4602:3 [opt]
frame #39: 0x0000000100007d38 emacs`sit_for(timeout=(EMACS_INT) $4 = 30, reading=true, display_option=1) at dispnew.c:6284:3 [opt]
frame #40: 0x00000001000d5ba0 emacs`read_char(commandflag=<unavailable>, map=<unavailable>, prev_event=<unavailable>, used_mouse_menu=<unavailable>, end_time=<unavailable>) at keyboard.c:2923:11 [opt]
frame #41: 0x00000001000d2ab0 emacs`read_key_sequence(keybuf=<unavailable>, prompt=(struct Lisp_Symbol *) $22 = 0x00000001008eefe0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<unavailable>, disable_text_conversion_p=<unavailable>) at keyboard.c:10743:12 [opt]
frame #42: 0x00000001000d0ee4 emacs`command_loop_1 at keyboard.c:1429:15 [opt]
frame #14: 0x000000018e16503c QuartzCore`-[CALayer _display] + 1636
frame #15: 0x0000000189608e94 AppKit`___lldb_unnamed_symbol172075 + 1372
frame #16: 0x00000001896096b0 AppKit`___lldb_unnamed_symbol172087 + 28
frame #17: 0x00000001894fc49c AppKit`___lldb_unnamed_symbol166799 + 148
frame #18: 0x0000000189608f88 AppKit`___lldb_unnamed_symbol172076 + 128
frame #19: 0x000000018e1641b8 QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 784
frame #20: 0x000000018e2f30e4 QuartzCore`CA::Context::commit_transaction(CA::Transaction*, double, double*) + 528
frame #21: 0x000000018e146780 QuartzCore`CA::Transaction::commit() + 648
frame #22: 0x000000018929da9c AppKit`__62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 272
frame #23: 0x0000000189ca88f4 AppKit`___NSRunLoopObserverCreateWithHandler_block_invoke + 64
frame #24: 0x0000000185603be8 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36
frame #25: 0x0000000185603ad4 CoreFoundation`__CFRunLoopDoObservers + 552
frame #26: 0x0000000185603104 CoreFoundation`__CFRunLoopRun + 788
frame #27: 0x0000000185602734 CoreFoundation`CFRunLoopRunSpecific + 588
frame #28: 0x0000000190b71530 HIToolbox`RunCurrentEventLoopInMode + 292
frame #29: 0x0000000190b7717c HIToolbox`ReceiveNextEventCommon + 216
frame #30: 0x0000000190b77508 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76
frame #31: 0x000000018917a848 AppKit`_DPSNextEvent + 660
frame #32: 0x0000000189ae0c24 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
frame #33: 0x000000018916d874 AppKit`-[NSApplication run] + 480
frame #34: 0x00000001001fbf44 emacs`-[EmacsApp run](self=0x0000000129722680, _cmd=<unavailable>) at nsterm.m:5938:7 [opt]
frame #35: 0x000000010020efb0 emacs`ns_read_socket_1(terminal=<unavailable>, hold_quit=<unavailable>, no_release=<unavailable>) at nsterm.m:4812:11 [opt]
frame #36: 0x00000001000dc838 emacs`gobble_input at keyboard.c:7919:17 [opt]
frame #37: 0x00000001000d8d80 emacs`swallow_events [inlined] get_input_pending(flags=1) at keyboard.c:7875:7 [opt]
frame #38: 0x00000001000d8d0c emacs`swallow_events(do_display=true) at keyboard.c:4602:3 [opt]
frame #39: 0x0000000100007d38 emacs`sit_for(timeout=(EMACS_INT) $4 = 30, reading=true, display_option=1) at dispnew.c:6284:3 [opt]
frame #40: 0x00000001000d5ba0 emacs`read_char(commandflag=<unavailable>, map=<unavailable>, prev_event=<unavailable>, used_mouse_menu=<unavailable>, end_time=<unavailable>) at keyboard.c:2923:11 [opt]
frame #41: 0x00000001000d2ab0 emacs`read_key_sequence(keybuf=<unavailable>, prompt=(struct Lisp_Symbol *) $22 = 0x00000001008eefe0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<unavailable>, disable_text_conversion_p=<unavailable>) at keyboard.c:10743:12 [opt]
frame #42: 0x00000001000d0ee4 emacs`command_loop_1 at keyboard.c:1429:15 [opt]
frame #43: 0x000000010015b994 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1324), handlers=<unavailable>, hfun=(emacs`cmd_error at keyboard.c:970)) at eval.c:1613:25 [opt]
frame #44: 0x00000001000d0b78 emacs`command_loop_2(handlers=(struct Lisp_Symbol *) $43 = 0x00000001008ef070) at keyboard.c:1168:11 [opt]
frame #45: 0x000000010015b030 emacs`internal_catch(tag=(struct Lisp_Symbol *) $64 = 0x00000001008f63f0, func=(emacs`command_loop_2 at keyboard.c:1164), arg=(struct Lisp_Symbol *) $85 = 0x00000001008ef070) at eval.c:1292:25 [opt]
frame #46: 0x00000001000d03a8 emacs`command_loop at keyboard.c:1138:13 [opt]
frame #47: 0x00000001000d0270 emacs`recursive_edit_1 at keyboard.c:754:9 [opt]
frame #48: 0x00000001001068c0 emacs`Fread_from_minibuffer [inlined] read_minibuf(map=<unavailable>, initial=<unavailable>, prompt=(struct Lisp_String *) $94 = 0x00000001297199a0, expflag=<unavailable>, histvar=<unavailable>, histpos=(EMACS_INT) $100 = 0, defalt=<unavailable>, allow_props=<unavailable>, inherit_input_method=<unavailable>) at minibuf.c:905:3 [opt]
frame #49: 0x0000000100105bf0 emacs`Fread_from_minibuffer(prompt=<unavailable>, initial_contents=<unavailable>, keymap=(struct Lisp_Cons *) $106 = 0x0000000102fe8910, read=<unavailable>, hist=<unavailable>, default_value=<unavailable>, inherit_input_method=(struct Lisp_Symbol *) $124 = 0x00000001008eefe0) at minibuf.c:1394:9 [opt]
frame #50: 0x00000001001a54f8 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:812:14 [opt]
frame #51: 0x000000010015e9f0 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3252:9 [opt] [artificial]
frame #52: 0x000000010015e298 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at lisp.h:0:43 [opt] [artificial]
frame #53: 0x0000000100159260 emacs`Ffuncall(nargs=9, args=(struct Lisp_Symbol *) $133 = 0x00000002706ed540) at eval.c:3093:21 [opt]
frame #54: 0x0000000100106f94 emacs`Fcompleting_read(prompt=(struct Lisp_String *) $139 = 0x00000001297199a0, collection=(struct Lisp_Vector *) $145 = 0x000000010285dd38, predicate=(struct Lisp_Vector *) $151 = 0x000000012a1d5748, require_match=(struct Lisp_Symbol *) $169 = 0x00000001008ef010, initial_input=(struct Lisp_Symbol *) $190 = 0x00000001008eefe0, hist=(struct Lisp_Symbol *) $211 = 0x000000010285c5c8, def=(struct Lisp_Symbol *) $232 = 0x00000001008eefe0, inherit_input_method=(struct Lisp_Symbol *) $253 = 0x00000001008eefe0) at minibuf.c:2049:10 [opt]
frame #55: 0x00000001001a54f8 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:812:14 [opt]
frame #56: 0x00000001001a4ad4 emacs`Fbyte_code(bytestr=<unavailable>, vector=(struct Lisp_Vector *) $262 = 0x000000010285c3d8, maxdepth=(EMACS_INT) $268 = 3) at bytecode.c:329:10 [opt]
frame #57: 0x00000001001588c0 emacs`eval_sub(form=(struct Lisp_Cons *) $274 = 0x000000010285c3a8) at eval.c:2604:15 [opt]
frame #58: 0x000000010015ce4c emacs`Feval(form=<unavailable>, lexical=<unavailable>) at eval.c:2462:28 [opt]
frame #59: 0x0000000100155f48 emacs`Fcall_interactively(function=<unavailable>, record_flag=(struct Lisp_Symbol *) $292 = 0x00000001008eefe0, keys=(struct Lisp_Vector *) $301 = 0x000000012a2505c0) at callint.c:325:15 [opt]
frame #60: 0x00000001001a54f8 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:812:14 [opt]
frame #61: 0x000000010015e9f0 emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3252:9 [opt] [artificial]
frame #62: 0x000000010015e298 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at lisp.h:0:43 [opt] [artificial]
frame #63: 0x0000000100159260 emacs`Ffuncall(nargs=2, args=(struct Lisp_Symbol *) $319 = 0x00000002706edbc0) at eval.c:3093:21 [opt]
frame #64: 0x00000001000d10e4 emacs`command_loop_1 at keyboard.c:1550:13 [opt]
frame #65: 0x000000010015b994 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1324), handlers=<unavailable>, hfun=(emacs`cmd_error at keyboard.c:970)) at eval.c:1613:25 [opt]
frame #66: 0x00000001000d0b78 emacs`command_loop_2(handlers=(struct Lisp_Symbol *) $340 = 0x00000001008ef070) at keyboard.c:1168:11 [opt]
frame #67: 0x000000010015b030 emacs`internal_catch(tag=<unavailable>, func=(emacs`command_loop_2 at keyboard.c:1164), arg=(struct Lisp_Symbol *) $361 = 0x00000001008ef070) at eval.c:1292:25 [opt]
frame #68: 0x000000010023ee7c emacs`command_loop.cold.1 at keyboard.c:1146:2 [opt]
frame #69: 0x00000001000d03c0 emacs`command_loop at keyboard.c:1145:2 [opt]
frame #70: 0x00000001000d0270 emacs`recursive_edit_1 at keyboard.c:754:9 [opt]
frame #71: 0x00000001000d0550 emacs`Frecursive_edit at keyboard.c:837:3 [opt]
frame #72: 0x00000001000cf300 emacs`main(argc=<unavailable>, argv=0x000000016fdff2c8) at emacs.c:2646:3 [opt]
frame #73: 0x000000018519c274 dyld`start + 2840
(lldb)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 05 Mar 2025 15:41:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Mar 5, 2025 at 8:44 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Wed, 5 Mar 2025 06:38:05 -0500, Ship Mints <shipmints <at> gmail.com>
> said:
>
> Ship> On Wed, Mar 5, 2025 at 4:04 AM Robert Pluim <rpluim <at> gmail.com>
> wrote:
> >> >>>>> On Tue, 4 Mar 2025 11:06:29 -0500, Ship Mints <
> shipmints <at> gmail.com>
> >> said:
> >>
> Ship> On Tue, Mar 4, 2025 at 10:59 AM Ship Mints <shipmints <at> gmail.com>
> >> wrote:
> >> >> On Tue, Mar 4, 2025 at 10:34 AM Robert Pluim <rpluim <at> 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.
> >>
>
> Ship> The way make-frame-on-monitor is implemented is nothing
> special. Just find
> Ship> the coordinates of the "workspace" occupied by the named monitor
> and use
> Ship> those as the basis for the new frame. The bt from yesterday's
> perhaps
> Ship> indicates some kind of guard might be needed for frame
> coordinates that
> Ship> might be out of bounds, perhaps? Do you think the frame on the
> second
> Ship> monitor was larger than the screen? I admit to not having
> played much with
> Ship> trying to make oversized frames but it happens to me
> occasionally if only
> Ship> over left and right by a column or row or two, not more.
>
> The default frame size is smaller than both monitors. I guess itʼs
> possible something decided to place it off screen.
>
> Ship> I'm curious what the read_char bt looks like. You saw the
> patch, it's
> Ship> pretty much a nothing. I updated it yesterday to use xstrdup
> instead of
> Ship> the two-step. I doubt that's anything. But here's the updated
> patch, just
> Ship> in case.
>
> It might be an existing emacs issue, rather than anything to do with
> your patch (if youʼre feeling inspired, rewriting the socket handling
> on macOS to use the normal event loop rather than the hackery with a
> separate thread to run select might improve the port a lot. Or it might
> make no difference)
>
> Anyway, Iʼm suspicious about the fact that `ns_read_socket' appears in
> this backtrace twice.
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
> * frame #0: 0x00000001854e3720 libsystem_kernel.dylib`__pthread_kill + 8
> frame #1: 0x000000018551bf70 libsystem_pthread.dylib`pthread_kill + 288
> frame #2: 0x0000000185428908 libsystem_c.dylib`abort + 128
> frame #3: 0x0000000185331e38 libsystem_malloc.dylib`malloc_vreport +
> 896
> frame #4: 0x000000018535a458 libsystem_malloc.dylib`malloc_zone_error
> + 100
> frame #5: 0x0000000185349774
> libsystem_malloc.dylib`nanov2_guard_corruption_detected + 44
> frame #6: 0x0000000185349734
> libsystem_malloc.dylib`nanov2_allocate_outlined + 460
> frame #7: 0x0000000185348468 libsystem_malloc.dylib`nanov2_calloc_type
> + 568
> frame #8: 0x000000018b69c610 CoreGraphics`CGGStackCreateWithGState + 40
> frame #9: 0x000000018b71b0b0
> CoreGraphics`CGDisplayListDrawInContextDelegate + 596
> frame #10: 0x0000000189590ee4 AppKit`___lldb_unnamed_symbol169773 + 884
> frame #11: 0x0000000189609008 AppKit`___lldb_unnamed_symbol172077 + 100
> frame #12: 0x000000018e165fbc QuartzCore`CABackingStoreUpdate_ + 284
> frame #13: 0x000000018e1bc2d8 QuartzCore`invocation function for block
> in CA::Layer::display_() + 120
> frame #14: 0x000000018e16503c QuartzCore`-[CALayer _display] + 1636
> frame #15: 0x0000000189608e94 AppKit`___lldb_unnamed_symbol172075 +
> 1372
> frame #16: 0x00000001896096b0 AppKit`___lldb_unnamed_symbol172087 + 28
> frame #17: 0x00000001894fc49c AppKit`___lldb_unnamed_symbol166799 + 148
> frame #18: 0x0000000189608f88 AppKit`___lldb_unnamed_symbol172076 + 128
> frame #19: 0x000000018e1641b8
> QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 784
> frame #20: 0x000000018e2f30e4
> QuartzCore`CA::Context::commit_transaction(CA::Transaction*, double,
> double*) + 528
> frame #21: 0x000000018e146780 QuartzCore`CA::Transaction::commit() +
> 648
> frame #22: 0x000000018929da9c
> AppKit`__62+[CATransaction(NSCATransaction)
> NS_setFlushesWithDisplayLink]_block_invoke + 272
> frame #23: 0x0000000189ca88f4
> AppKit`___NSRunLoopObserverCreateWithHandler_block_invoke + 64
> frame #24: 0x0000000185603be8
> CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
> + 36
> frame #25: 0x0000000185603ad4 CoreFoundation`__CFRunLoopDoObservers +
> 552
> frame #26: 0x0000000185603104 CoreFoundation`__CFRunLoopRun + 788
> frame #27: 0x0000000185602734 CoreFoundation`CFRunLoopRunSpecific + 588
> frame #28: 0x0000000190b71530 HIToolbox`RunCurrentEventLoopInMode + 292
> frame #29: 0x0000000190b7717c HIToolbox`ReceiveNextEventCommon + 216
> frame #30: 0x0000000190b77508
> HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76
> frame #31: 0x000000018917a848 AppKit`_DPSNextEvent + 660
> frame #32: 0x0000000189ae0c24 AppKit`-[NSApplication(NSEventRouting)
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
> frame #33: 0x000000018916d874 AppKit`-[NSApplication run] + 480
> frame #34: 0x00000001001fbf44 emacs`-[EmacsApp
> run](self=0x0000000129722680, _cmd=<unavailable>) at nsterm.m:5938:7 [opt]
> frame #35: 0x000000010020efb0
> emacs`ns_read_socket_1(terminal=<unavailable>, hold_quit=<unavailable>,
> no_release=<unavailable>) at nsterm.m:4812:11 [opt]
> frame #36: 0x00000001000dc838 emacs`gobble_input at keyboard.c:7919:17
> [opt]
> frame #37: 0x00000001000d8d80 emacs`swallow_events [inlined]
> get_input_pending(flags=1) at keyboard.c:7875:7 [opt]
> frame #38: 0x00000001000d8d0c emacs`swallow_events(do_display=true) at
> keyboard.c:4602:3 [opt]
> frame #39: 0x0000000100007d38 emacs`sit_for(timeout=(EMACS_INT) $4 =
> 30, reading=true, display_option=1) at dispnew.c:6284:3 [opt]
> frame #40: 0x00000001000d5ba0
> emacs`read_char(commandflag=<unavailable>, map=<unavailable>,
> prev_event=<unavailable>, used_mouse_menu=<unavailable>,
> end_time=<unavailable>) at keyboard.c:2923:11 [opt]
> frame #41: 0x00000001000d2ab0
> emacs`read_key_sequence(keybuf=<unavailable>, prompt=(struct Lisp_Symbol *)
> $22 = 0x00000001008eefe0, dont_downcase_last=false,
> can_return_switch_frame=true, fix_current_buffer=true,
> prevent_redisplay=<unavailable>, disable_text_conversion_p=<unavailable>)
> at keyboard.c:10743:12 [opt]
> frame #42: 0x00000001000d0ee4 emacs`command_loop_1 at
> keyboard.c:1429:15 [opt]
> frame #14: 0x000000018e16503c QuartzCore`-[CALayer _display] + 1636
> frame #15: 0x0000000189608e94 AppKit`___lldb_unnamed_symbol172075 +
> 1372
> frame #16: 0x00000001896096b0 AppKit`___lldb_unnamed_symbol172087 + 28
> frame #17: 0x00000001894fc49c AppKit`___lldb_unnamed_symbol166799 + 148
> frame #18: 0x0000000189608f88 AppKit`___lldb_unnamed_symbol172076 + 128
> frame #19: 0x000000018e1641b8
> QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 784
> frame #20: 0x000000018e2f30e4
> QuartzCore`CA::Context::commit_transaction(CA::Transaction*, double,
> double*) + 528
> frame #21: 0x000000018e146780 QuartzCore`CA::Transaction::commit() +
> 648
> frame #22: 0x000000018929da9c
> AppKit`__62+[CATransaction(NSCATransaction)
> NS_setFlushesWithDisplayLink]_block_invoke + 272
> frame #23: 0x0000000189ca88f4
> AppKit`___NSRunLoopObserverCreateWithHandler_block_invoke + 64
> frame #24: 0x0000000185603be8
> CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
> + 36
> frame #25: 0x0000000185603ad4 CoreFoundation`__CFRunLoopDoObservers +
> 552
> frame #26: 0x0000000185603104 CoreFoundation`__CFRunLoopRun + 788
> frame #27: 0x0000000185602734 CoreFoundation`CFRunLoopRunSpecific + 588
> frame #28: 0x0000000190b71530 HIToolbox`RunCurrentEventLoopInMode + 292
> frame #29: 0x0000000190b7717c HIToolbox`ReceiveNextEventCommon + 216
> frame #30: 0x0000000190b77508
> HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76
> frame #31: 0x000000018917a848 AppKit`_DPSNextEvent + 660
> frame #32: 0x0000000189ae0c24 AppKit`-[NSApplication(NSEventRouting)
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
> frame #33: 0x000000018916d874 AppKit`-[NSApplication run] + 480
> frame #34: 0x00000001001fbf44 emacs`-[EmacsApp
> run](self=0x0000000129722680, _cmd=<unavailable>) at nsterm.m:5938:7 [opt]
> frame #35: 0x000000010020efb0
> emacs`ns_read_socket_1(terminal=<unavailable>, hold_quit=<unavailable>,
> no_release=<unavailable>) at nsterm.m:4812:11 [opt]
> frame #36: 0x00000001000dc838 emacs`gobble_input at keyboard.c:7919:17
> [opt]
> frame #37: 0x00000001000d8d80 emacs`swallow_events [inlined]
> get_input_pending(flags=1) at keyboard.c:7875:7 [opt]
> frame #38: 0x00000001000d8d0c emacs`swallow_events(do_display=true) at
> keyboard.c:4602:3 [opt]
> frame #39: 0x0000000100007d38 emacs`sit_for(timeout=(EMACS_INT) $4 =
> 30, reading=true, display_option=1) at dispnew.c:6284:3 [opt]
> frame #40: 0x00000001000d5ba0
> emacs`read_char(commandflag=<unavailable>, map=<unavailable>,
> prev_event=<unavailable>, used_mouse_menu=<unavailable>,
> end_time=<unavailable>) at keyboard.c:2923:11 [opt]
> frame #41: 0x00000001000d2ab0
> emacs`read_key_sequence(keybuf=<unavailable>, prompt=(struct Lisp_Symbol *)
> $22 = 0x00000001008eefe0, dont_downcase_last=false,
> can_return_switch_frame=true, fix_current_buffer=true,
> prevent_redisplay=<unavailable>, disable_text_conversion_p=<unavailable>)
> at keyboard.c:10743:12 [opt]
> frame #42: 0x00000001000d0ee4 emacs`command_loop_1 at
> keyboard.c:1429:15 [opt]
> frame #43: 0x000000010015b994
> emacs`internal_condition_case(bfun=(emacs`command_loop_1 at
> keyboard.c:1324), handlers=<unavailable>, hfun=(emacs`cmd_error at
> keyboard.c:970)) at eval.c:1613:25 [opt]
> frame #44: 0x00000001000d0b78 emacs`command_loop_2(handlers=(struct
> Lisp_Symbol *) $43 = 0x00000001008ef070) at keyboard.c:1168:11 [opt]
> frame #45: 0x000000010015b030 emacs`internal_catch(tag=(struct
> Lisp_Symbol *) $64 = 0x00000001008f63f0, func=(emacs`command_loop_2 at
> keyboard.c:1164), arg=(struct Lisp_Symbol *) $85 = 0x00000001008ef070) at
> eval.c:1292:25 [opt]
> frame #46: 0x00000001000d03a8 emacs`command_loop at keyboard.c:1138:13
> [opt]
> frame #47: 0x00000001000d0270 emacs`recursive_edit_1 at
> keyboard.c:754:9 [opt]
> frame #48: 0x00000001001068c0 emacs`Fread_from_minibuffer [inlined]
> read_minibuf(map=<unavailable>, initial=<unavailable>, prompt=(struct
> Lisp_String *) $94 = 0x00000001297199a0, expflag=<unavailable>,
> histvar=<unavailable>, histpos=(EMACS_INT) $100 = 0, defalt=<unavailable>,
> allow_props=<unavailable>, inherit_input_method=<unavailable>) at
> minibuf.c:905:3 [opt]
> frame #49: 0x0000000100105bf0
> emacs`Fread_from_minibuffer(prompt=<unavailable>,
> initial_contents=<unavailable>, keymap=(struct Lisp_Cons *) $106 =
> 0x0000000102fe8910, read=<unavailable>, hist=<unavailable>,
> default_value=<unavailable>, inherit_input_method=(struct Lisp_Symbol *)
> $124 = 0x00000001008eefe0) at minibuf.c:1394:9 [opt]
> frame #50: 0x00000001001a54f8 emacs`exec_byte_code(fun=<unavailable>,
> args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at
> bytecode.c:812:14 [opt]
> frame #51: 0x000000010015e9f0 emacs`funcall_lambda(fun=<unavailable>,
> nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3252:9 [opt]
> [artificial]
> frame #52: 0x000000010015e298 emacs`funcall_general(fun=<unavailable>,
> numargs=<unavailable>, args=<unavailable>) at lisp.h:0:43 [opt] [artificial]
> frame #53: 0x0000000100159260 emacs`Ffuncall(nargs=9, args=(struct
> Lisp_Symbol *) $133 = 0x00000002706ed540) at eval.c:3093:21 [opt]
> frame #54: 0x0000000100106f94 emacs`Fcompleting_read(prompt=(struct
> Lisp_String *) $139 = 0x00000001297199a0, collection=(struct Lisp_Vector *)
> $145 = 0x000000010285dd38, predicate=(struct Lisp_Vector *) $151 =
> 0x000000012a1d5748, require_match=(struct Lisp_Symbol *) $169 =
> 0x00000001008ef010, initial_input=(struct Lisp_Symbol *) $190 =
> 0x00000001008eefe0, hist=(struct Lisp_Symbol *) $211 = 0x000000010285c5c8,
> def=(struct Lisp_Symbol *) $232 = 0x00000001008eefe0,
> inherit_input_method=(struct Lisp_Symbol *) $253 = 0x00000001008eefe0) at
> minibuf.c:2049:10 [opt]
> frame #55: 0x00000001001a54f8 emacs`exec_byte_code(fun=<unavailable>,
> args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at
> bytecode.c:812:14 [opt]
> frame #56: 0x00000001001a4ad4 emacs`Fbyte_code(bytestr=<unavailable>,
> vector=(struct Lisp_Vector *) $262 = 0x000000010285c3d8,
> maxdepth=(EMACS_INT) $268 = 3) at bytecode.c:329:10 [opt]
> frame #57: 0x00000001001588c0 emacs`eval_sub(form=(struct Lisp_Cons *)
> $274 = 0x000000010285c3a8) at eval.c:2604:15 [opt]
> frame #58: 0x000000010015ce4c emacs`Feval(form=<unavailable>,
> lexical=<unavailable>) at eval.c:2462:28 [opt]
> frame #59: 0x0000000100155f48
> emacs`Fcall_interactively(function=<unavailable>, record_flag=(struct
> Lisp_Symbol *) $292 = 0x00000001008eefe0, keys=(struct Lisp_Vector *) $301
> = 0x000000012a2505c0) at callint.c:325:15 [opt]
> frame #60: 0x00000001001a54f8 emacs`exec_byte_code(fun=<unavailable>,
> args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at
> bytecode.c:812:14 [opt]
> frame #61: 0x000000010015e9f0 emacs`funcall_lambda(fun=<unavailable>,
> nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3252:9 [opt]
> [artificial]
> frame #62: 0x000000010015e298 emacs`funcall_general(fun=<unavailable>,
> numargs=<unavailable>, args=<unavailable>) at lisp.h:0:43 [opt] [artificial]
> frame #63: 0x0000000100159260 emacs`Ffuncall(nargs=2, args=(struct
> Lisp_Symbol *) $319 = 0x00000002706edbc0) at eval.c:3093:21 [opt]
> frame #64: 0x00000001000d10e4 emacs`command_loop_1 at
> keyboard.c:1550:13 [opt]
> frame #65: 0x000000010015b994
> emacs`internal_condition_case(bfun=(emacs`command_loop_1 at
> keyboard.c:1324), handlers=<unavailable>, hfun=(emacs`cmd_error at
> keyboard.c:970)) at eval.c:1613:25 [opt]
> frame #66: 0x00000001000d0b78 emacs`command_loop_2(handlers=(struct
> Lisp_Symbol *) $340 = 0x00000001008ef070) at keyboard.c:1168:11 [opt]
> frame #67: 0x000000010015b030 emacs`internal_catch(tag=<unavailable>,
> func=(emacs`command_loop_2 at keyboard.c:1164), arg=(struct Lisp_Symbol *)
> $361 = 0x00000001008ef070) at eval.c:1292:25 [opt]
> frame #68: 0x000000010023ee7c emacs`command_loop.cold.1 at
> keyboard.c:1146:2 [opt]
> frame #69: 0x00000001000d03c0 emacs`command_loop at keyboard.c:1145:2
> [opt]
> frame #70: 0x00000001000d0270 emacs`recursive_edit_1 at
> keyboard.c:754:9 [opt]
> frame #71: 0x00000001000d0550 emacs`Frecursive_edit at
> keyboard.c:837:3 [opt]
> frame #72: 0x00000001000cf300 emacs`main(argc=<unavailable>,
> argv=0x000000016fdff2c8) at emacs.c:2646:3 [opt]
> frame #73: 0x000000018519c274 dyld`start + 2840
> (lldb)
>
Hmm. I never see these. I wonder what's different about your set up.
These seem independent of the NS display name improvement.
Should we push the display name patch and see what feedback we get from a
larger audience? It seems low risk vs. rewriting macOS socket handling.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 05 Mar 2025 15:55:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 5 Mar 2025 10:40:11 -0500, Ship Mints <shipmints <at> gmail.com> said:
Ship> Hmm. I never see these. I wonder what's different about your set up.
Ship> These seem independent of the NS display name improvement.
Yes, I doubt itʼs related. Itʼs also hard to reproduce.
Ship> Should we push the display name patch and see what feedback we get from a
Ship> larger audience? It seems low risk vs. rewriting macOS socket handling.
You can only push the patch as-is if the maintainers agree that
removing the old methods for getting the display name is appropriate.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 05 Mar 2025 15:56:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Mar 5, 2025 at 10:54 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Wed, 5 Mar 2025 10:40:11 -0500, Ship Mints <shipmints <at> gmail.com>
> said:
>
> Ship> Hmm. I never see these. I wonder what's different about your
> set up.
> Ship> These seem independent of the NS display name improvement.
>
> Yes, I doubt itʼs related. Itʼs also hard to reproduce.
>
> Ship> Should we push the display name patch and see what feedback we
> get from a
> Ship> larger audience? It seems low risk vs. rewriting macOS socket
> handling.
>
> You can only push the patch as-is if the maintainers agree that
> removing the old methods for getting the display name is appropriate.
>
The old methods don't work and seem to have been broken for a long time.
Let's see what they think.
[Message part 2 (text/html, inline)]
Added tag(s) patch.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Wed, 05 Mar 2025 19:37:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 05 Mar 2025 23:21:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The updated patch also works for me. Thanks for your great work!
Ruiyang
> On Mar 5, 2025, at 10:55 AM, Ship Mints <shipmints <at> gmail.com> wrote:
>
> On Wed, Mar 5, 2025 at 10:54 AM Robert Pluim <rpluim <at> gmail.com <mailto:rpluim <at> gmail.com>> wrote:
>> >>>>> On Wed, 5 Mar 2025 10:40:11 -0500, Ship Mints <shipmints <at> gmail.com <mailto:shipmints <at> gmail.com>> said:
>>
>> Ship> Hmm. I never see these. I wonder what's different about your set up.
>> Ship> These seem independent of the NS display name improvement.
>>
>> Yes, I doubt itʼs related. Itʼs also hard to reproduce.
>>
>> Ship> Should we push the display name patch and see what feedback we get from a
>> Ship> larger audience? It seems low risk vs. rewriting macOS socket handling.
>>
>> You can only push the patch as-is if the maintainers agree that
>> removing the old methods for getting the display name is appropriate.
>
> The old methods don't work and seem to have been broken for a long time. Let's see what they think.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Thu, 06 Mar 2025 10:09:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 5 Mar 2025 06:38:05 -0500, Ship Mints <shipmints <at> gmail.com> said:
Ship> #ifdef NS_IMPL_COCOA
Ship> - m->name = ns_screen_name (did);
Ship> + m->name = NULL;
Ship> + if ([s respondsToSelector:@selector(localizedName)])
Ship> + {
Ship> + NSString *name = [s valueForKey:@"localizedName"];
Ship> + if (name != NULL)
Ship> + {
Ship> + m->name = xmalloc ([name lengthOfBytesUsingEncoding: NSUTF8StringEncoding]);
Ship> + strcpy(m->name, [name UTF8String]);
Ship> + }
The reason it was crashing for me is that the xmalloc doesnʼt account
for the terminating '\0', ie we need
m->name = xmalloc ([name lengthOfBytesUsingEncoding: NSUTF8StringEncoding] + 1);
or just
m->name = xstrdup ([name UTF8String]);
Ship> + }
Ship> + /* If necessary, synthesize a name of the following form:
Ship> + %dx%d@%d,%d width height x y. */
Ship> + if (m->name == NULL)
Ship> + {
Ship> + char buf[25]; /* sufficient for 12345x78901 <at> 34567,90123 */
Ship> + snprintf (buf, sizeof(buf), "%ux%u@%d,%d",
Ship> + m->work.width, m->work.height, m->work.x, m->work.y);
Ship> + m->name = xstrdup (buf);
Ship> + }
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Thu, 06 Mar 2025 11:24:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Mar 6, 2025 at 05:08 Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Wed, 5 Mar 2025 06:38:05 -0500, Ship Mints <shipmints <at> gmail.com>
> said:
>
> Ship> #ifdef NS_IMPL_COCOA
> Ship> - m->name = ns_screen_name (did);
> Ship> + m->name = NULL;
> Ship> + if ([s respondsToSelector:@selector(localizedName)])
> Ship> + {
> Ship> + NSString *name = [s valueForKey:@"localizedName"];
> Ship> + if (name != NULL)
> Ship> + {
> Ship> + m->name = xmalloc ([name lengthOfBytesUsingEncoding:
> NSUTF8StringEncoding]);
> Ship> + strcpy(m->name, [name UTF8String]);
> Ship> + }
>
> The reason it was crashing for me is that the xmalloc doesnʼt account
> for the terminating '\0', ie we need
>
> m->name = xmalloc ([name lengthOfBytesUsingEncoding:
> NSUTF8StringEncoding] + 1);
>
> or just
>
> m->name = xstrdup ([name UTF8String]);
>
> Ship> + }
> Ship> + /* If necessary, synthesize a name of the following form:
> Ship> + %dx%d@%d,%d width height x y. */
> Ship> + if (m->name == NULL)
> Ship> + {
> Ship> + char buf[25]; /* sufficient for 12345x78901 <at> 34567,90123
> */
> Ship> + snprintf (buf, sizeof(buf), "%ux%u@%d,%d",
> Ship> + m->work.width, m->work.height, m->work.x,
> m->work.y);
> Ship> + m->name = xstrdup (buf);
> Ship> + }
Right. I'd changed the last patch to xstrdup.
Do you have a monitor for which macOS has no name that caused the fallback
to be invoked?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Thu, 06 Mar 2025 13:29:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 6 Mar 2025 06:19:25 -0500, Ship Mints <shipmints <at> gmail.com> said:
Ship> Right. I'd changed the last patch to xstrdup.
OK
Ship> Do you have a monitor for which macOS has no name that caused the fallback
Ship> to be invoked?
I donʼt, although it works fine if I comment out the localizeName
code.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Sun, 16 Mar 2025 21:43:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Mar 6, 2025 at 8:27 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Thu, 6 Mar 2025 06:19:25 -0500, Ship Mints <shipmints <at> gmail.com>
> said:
>
> Ship> Right. I'd changed the last patch to xstrdup.
>
> OK
>
> Ship> Do you have a monitor for which macOS has no name that caused
> the fallback
> Ship> to be invoked?
>
> I donʼt, although it works fine if I comment out the localizeName
> code.
>
Fixed in the last version of the patch; I used xstrdup.
Anything else needed for this before we can install it?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Mon, 07 Apr 2025 05:12:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi all,
How can we move this forward? It would be great to see Ship Mints' patch merged to master and backported to emacs-30.
Best,
Ruiyang
> On Mar 16, 2025, at 5:42 PM, Ship Mints <shipmints <at> gmail.com> wrote:
>
> On Thu, Mar 6, 2025 at 8:27 AM Robert Pluim <rpluim <at> gmail.com <mailto:rpluim <at> gmail.com>> wrote:
>> >>>>> On Thu, 6 Mar 2025 06:19:25 -0500, Ship Mints <shipmints <at> gmail.com <mailto:shipmints <at> gmail.com>> said:
>>
>> Ship> Right. I'd changed the last patch to xstrdup.
>>
>> OK
>>
>> Ship> Do you have a monitor for which macOS has no name that caused the fallback
>> Ship> to be invoked?
>>
>> I donʼt, although it works fine if I comment out the localizeName
>> code.
>
> Fixed in the last version of the patch; I used xstrdup.
>
> Anything else needed for this before we can install it?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Mon, 26 May 2025 21:18:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 76691 <at> debbugs.gnu.org (full text, mbox):
package emacs
merge 76691 76051
user emacs
usertag 76691 + ns
thankyou
On Mon, Apr 07, 2025 at 01:10:49AM -0400, Ruiyang Wu wrote:
> Hi all,
>
> How can we move this forward? It would be great to see Ship Mints'
> patch merged to master and backported to emacs-30.
Is there anything blocking this other than getting the OK from the
maintainers? I'm inclined to say it's good to go as the existing names
don't work at all, afaik, so we can't be any worse off than we were
before.
Stephane, when you get a chance can you forward the latest version of
this patch so I can compare it with my patch for 76051 so we can see
if they're covering the same ground? Thanks.
--
Alan Third
Merged 76051 76691.
Request was from
Alan Third <alan <at> idiocy.org>
to
control <at> debbugs.gnu.org.
(Mon, 26 May 2025 21:18:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Mon, 26 May 2025 22:45:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, May 26, 2025 at 5:17 PM Alan Third <alan <at> idiocy.org> wrote:
> package emacs
> merge 76691 76051
> user emacs
> usertag 76691 + ns
> thankyou
>
> On Mon, Apr 07, 2025 at 01:10:49AM -0400, Ruiyang Wu wrote:
> > Hi all,
> >
> > How can we move this forward? It would be great to see Ship Mints'
> > patch merged to master and backported to emacs-30.
>
> Is there anything blocking this other than getting the OK from the
> maintainers? I'm inclined to say it's good to go as the existing names
> don't work at all, afaik, so we can't be any worse off than we were
> before.
>
> Stephane, when you get a chance can you forward the latest version of
> this patch so I can compare it with my patch for 76051 so we can see
> if they're covering the same ground? Thanks.
>
See attached. I didn't rebase this recently but I doubt nsfns.m has
changed much, if at all.
-Stephane
[Message part 2 (text/html, inline)]
[0001-Improve-NS-display-names-in-display-monitor-attribut.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 28 May 2025 18:16:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 76691 <at> debbugs.gnu.org (full text, mbox):
On Mon, May 26, 2025 at 06:43:54PM -0400, Ship Mints wrote:
> On Mon, May 26, 2025 at 5:17 PM Alan Third <alan <at> idiocy.org> wrote:
>
> > package emacs
> > merge 76691 76051
> > user emacs
> > usertag 76691 + ns
> > thankyou
> >
> > On Mon, Apr 07, 2025 at 01:10:49AM -0400, Ruiyang Wu wrote:
> > > Hi all,
> > >
> > > How can we move this forward? It would be great to see Ship Mints'
> > > patch merged to master and backported to emacs-30.
> >
> > Is there anything blocking this other than getting the OK from the
> > maintainers? I'm inclined to say it's good to go as the existing names
> > don't work at all, afaik, so we can't be any worse off than we were
> > before.
> >
> > Stephane, when you get a chance can you forward the latest version of
> > this patch so I can compare it with my patch for 76051 so we can see
> > if they're covering the same ground? Thanks.
> >
>
> See attached. I didn't rebase this recently but I doubt nsfns.m has
> changed much, if at all.
It applied cleanly alongside my patch, so I think we're good. I'll do
a test build in a bit and I think we can get both patches pushed up
once someone with two screen checks mine.
Do you want to finish off the commit message or should I give it a go?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Wed, 28 May 2025 19:18:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, May 28, 2025 at 2:15 PM Alan Third <alan <at> idiocy.org> wrote:
> On Mon, May 26, 2025 at 06:43:54PM -0400, Ship Mints wrote:
> > On Mon, May 26, 2025 at 5:17 PM Alan Third <alan <at> idiocy.org> wrote:
> >
> > > package emacs
> > > merge 76691 76051
> > > user emacs
> > > usertag 76691 + ns
> > > thankyou
> > >
> > > On Mon, Apr 07, 2025 at 01:10:49AM -0400, Ruiyang Wu wrote:
> > > > Hi all,
> > > >
> > > > How can we move this forward? It would be great to see Ship Mints'
> > > > patch merged to master and backported to emacs-30.
> > >
> > > Is there anything blocking this other than getting the OK from the
> > > maintainers? I'm inclined to say it's good to go as the existing names
> > > don't work at all, afaik, so we can't be any worse off than we were
> > > before.
> > >
> > > Stephane, when you get a chance can you forward the latest version of
> > > this patch so I can compare it with my patch for 76051 so we can see
> > > if they're covering the same ground? Thanks.
> > >
> >
> > See attached. I didn't rebase this recently but I doubt nsfns.m has
> > changed much, if at all.
>
> It applied cleanly alongside my patch, so I think we're good. I'll do
> a test build in a bit and I think we can get both patches pushed up
> once someone with two screen checks mine.
>
> Do you want to finish off the commit message or should I give it a go?
>
Nice. Not home where I have that branch locally, so writing this
manually...
*snip*
Fix ns_make_monitor_attribute_list (bug#76691)
This is the NS implementation for 'display-monitor-attributes-list'.
Change implementation from IORegistry to direct introspection
of NSScreen.
* src/nsfns.m (ns_make_monitor_attribute_list): Use localizedName
selector on NSScreen. For anonymous displays, synthesize names
of the form ("%dx%d@%d,%d" width height x y).
(ns_get_name_from_ioreg) (ns_screen_name): Removed.
*snip*
Feel free to adapt, and thank you.
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Mon, 02 Jun 2025 08:03:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 28 May 2025 15:17:33 -0400, Ship Mints <shipmints <at> gmail.com> said:
>> It applied cleanly alongside my patch, so I think we're good. I'll do
>> a test build in a bit and I think we can get both patches pushed up
>> once someone with two screen checks mine.
>>
>> Do you want to finish off the commit message or should I give it a go?
>>
Ship> Nice. Not home where I have that branch locally, so writing this
Ship> manually...
Ship> *snip*
Ship> Fix ns_make_monitor_attribute_list (bug#76691)
Ship> This is the NS implementation for 'display-monitor-attributes-list'.
Ship> Change implementation from IORegistry to direct introspection
Ship> of NSScreen.
Ship> * src/nsfns.m (ns_make_monitor_attribute_list): Use localizedName
Ship> selector on NSScreen. For anonymous displays, synthesize names
Ship> of the form ("%dx%d@%d,%d" width height x y).
Ship> (ns_get_name_from_ioreg) (ns_screen_name): Removed.
Ship> *snip*
The latest version of your patch that I can see still doesnʼt allocate
space for the '\0' at the end of the monitor name for the
localizedName case.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Mon, 02 Jun 2025 10:53:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 76691 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Jun 2, 2025 at 4:02 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Wed, 28 May 2025 15:17:33 -0400, Ship Mints <shipmints <at> gmail.com>
> said:
> >> It applied cleanly alongside my patch, so I think we're good. I'll
> do
> >> a test build in a bit and I think we can get both patches pushed up
> >> once someone with two screen checks mine.
> >>
> >> Do you want to finish off the commit message or should I give it a
> go?
> >>
>
> Ship> Nice. Not home where I have that branch locally, so writing this
> Ship> manually...
>
> Ship> *snip*
> Ship> Fix ns_make_monitor_attribute_list (bug#76691)
>
> Ship> This is the NS implementation for
> 'display-monitor-attributes-list'.
> Ship> Change implementation from IORegistry to direct introspection
> Ship> of NSScreen.
>
> Ship> * src/nsfns.m (ns_make_monitor_attribute_list): Use localizedName
> Ship> selector on NSScreen. For anonymous displays, synthesize names
> Ship> of the form ("%dx%d@%d,%d" width height x y).
> Ship> (ns_get_name_from_ioreg) (ns_screen_name): Removed.
> Ship> *snip*
>
> The latest version of your patch that I can see still doesnʼt allocate
> space for the '\0' at the end of the monitor name for the
> localizedName case.
>
Robert, thank you for keen eyes a second time. This was a version I found
in my email, perhaps there was a later one on my other computer.
Alan, can you please change the name allocation to be:
m->name = xmalloc ([name lengthOfBytesUsingEncoding:
NSUTF8StringEncoding] + 1);
Thanks,
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Mon, 02 Jun 2025 12:45:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 76691 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 2 Jun 2025 06:52:35 -0400, Ship Mints <shipmints <at> gmail.com> said:
Ship> Robert, thank you for keen eyes a second time. This was a version I found
Ship> in my email, perhaps there was a later one on my other computer.
Wasnʼt my eyes, it was emacs crashing 😀
Ship> Alan, can you please change the name allocation to be:
m-> name = xmalloc ([name lengthOfBytesUsingEncoding:
Ship> NSUTF8StringEncoding] + 1);
Yes, thatʼs what I tested locally.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76691; Package
emacs.
(Mon, 02 Jun 2025 17:40:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 76691 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jun 02, 2025 at 06:52:35AM -0400, Ship Mints wrote:
> On Mon, Jun 2, 2025 at 4:02 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>
> > >>>>> On Wed, 28 May 2025 15:17:33 -0400, Ship Mints <shipmints <at> gmail.com>
> > said:
> > >> It applied cleanly alongside my patch, so I think we're good. I'll
> > do
> > >> a test build in a bit and I think we can get both patches pushed up
> > >> once someone with two screen checks mine.
> > >>
> > >> Do you want to finish off the commit message or should I give it a
> > go?
> > >>
> >
> > Ship> Nice. Not home where I have that branch locally, so writing this
> > Ship> manually...
> >
> > Ship> *snip*
> > Ship> Fix ns_make_monitor_attribute_list (bug#76691)
> >
> > Ship> This is the NS implementation for
> > 'display-monitor-attributes-list'.
> > Ship> Change implementation from IORegistry to direct introspection
> > Ship> of NSScreen.
> >
> > Ship> * src/nsfns.m (ns_make_monitor_attribute_list): Use localizedName
> > Ship> selector on NSScreen. For anonymous displays, synthesize names
> > Ship> of the form ("%dx%d@%d,%d" width height x y).
> > Ship> (ns_get_name_from_ioreg) (ns_screen_name): Removed.
> > Ship> *snip*
> >
> > The latest version of your patch that I can see still doesnʼt allocate
> > space for the '\0' at the end of the monitor name for the
> > localizedName case.
> >
>
> Robert, thank you for keen eyes a second time. This was a version I found
> in my email, perhaps there was a later one on my other computer.
>
> Alan, can you please change the name allocation to be:
>
> m->name = xmalloc ([name lengthOfBytesUsingEncoding:
> NSUTF8StringEncoding] + 1);
OK, I've pushed it up to master. I'm going to leave the patch for
bug#76051 (geometry) until someone has tried it out, but because the
bugs are merged I think I need to leave them both open for now.
Thanks!
--
Alan Third
This bug report was last modified 11 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.