bug#34516: Multi-monitor frame sets

bug#34516: Multi-monitor frame sets

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

Shouldn't frame.el provide a command like make-frame-on-display,
but to make a frame on the specified monitor instead of display?

Isn't the following patch the right way to do this?
(It also adds completion for the existing command):


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: make-frame-on-monitor.patch --]
[-- Type: text/x-diff, Size: 1958 bytes --]

diff --git a/lisp/frame.el b/lisp/frame.el
index dc81302939..38f2653905 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -644,9 +644,33 @@ window-system-for-display
 (defun make-frame-on-display (display &optional parameters)
   "Make a frame on display DISPLAY.
 The optional argument PARAMETERS specifies additional frame parameters."
-  (interactive "sMake frame on display: ")
+  (interactive (list (completing-read
+                      (format "Make frame on display: ")
+                      (delete-dups
+                       (mapcar (lambda (frame)
+                                 (frame-parameter frame 'display))
+                               (frame-list))))))
   (make-frame (cons (cons 'display display) parameters)))
 
+(defun make-frame-on-monitor (monitor &optional parameters)
+  "Make a frame on monitor MONITOR.
+The optional argument PARAMETERS specifies additional frame parameters."
+  (interactive (list (completing-read
+                      (format "Make frame on monitor: ")
+                      (mapcar (lambda (a)
+                                (cdr (assq 'name a)))
+                              (display-monitor-attributes-list)))))
+  (let ((geometry (car (delq nil (mapcar (lambda (a)
+                                           (when (equal (cdr (assq 'name a)) monitor)
+                                             (cdr (assq 'geometry a))))
+                                         (display-monitor-attributes-list))))))
+    (make-frame (append (x-parse-geometry (format "%dx%d+%d+%d"
+                                                  (nth 2 geometry)
+                                                  (nth 3 geometry)
+                                                  (nth 0 geometry)
+                                                  (nth 1 geometry)))
+                        parameters))))
+
 (declare-function x-close-connection "xfns.c" (terminal))
 
 (defun close-display-connection (display)

bug#34516: Multi-monitor frame sets

[Robert Pluim]

Juri Linkov <juri@linkov.net> writes:

> Shouldn't frame.el provide a command like make-frame-on-display,
> but to make a frame on the specified monitor instead of display?
>
> Isn't the following patch the right way to do this?
> (It also adds completion for the existing command):
>

I donʼt mind it, but it won't work on macOS, since thereʼs no 'name
entries in 'display-monitor-attributes-list' (and adding them looks
non-trivial, unless we go for 'Monitor-1', Monitor-2' etc.)

Robert

bug#34516: Multi-monitor frame sets

[Juri Linkov]

> Juri Linkov <juri@linkov.net> writes:
>
>> Shouldn't frame.el provide a command like make-frame-on-display,
>> but to make a frame on the specified monitor instead of display?
>>
>> Isn't the following patch the right way to do this?
>> (It also adds completion for the existing command):
>>
>
> I donʼt mind it, but it won't work on macOS, since thereʼs no 'name
> entries in 'display-monitor-attributes-list' (and adding them looks
> non-trivial, unless we go for 'Monitor-1', Monitor-2' etc.)

Are there other NS-specific attributes that could provide
a clear reference to a specific monitor?  Maybe ‘geometry’
could be used to deduce a relative arrangement of monitors?

bug#34516: Multi-monitor frame sets

[Robert Pluim]

Juri Linkov <juri@linkov.net> writes:

>> Juri Linkov <juri@linkov.net> writes:
>>
>>> Shouldn't frame.el provide a command like make-frame-on-display,
>>> but to make a frame on the specified monitor instead of display?
>>>
>>> Isn't the following patch the right way to do this?
>>> (It also adds completion for the existing command):
>>>
>>
>> I donʼt mind it, but it won't work on macOS, since thereʼs no 'name
>> entries in 'display-monitor-attributes-list' (and adding them looks
>> non-trivial, unless we go for 'Monitor-1', Monitor-2' etc.)
>
> Are there other NS-specific attributes that could provide
> a clear reference to a specific monitor?  Maybe ‘geometry’
> could be used to deduce a relative arrangement of monitors?

I guess it could. Or we could fake up a monitor name on those systems
where ns_screen_name doesnʼt work.

Robert

bug#34516: Multi-monitor frame sets

[Juri Linkov]

>>> I donʼt mind it, but it won't work on macOS, since thereʼs no 'name
>>> entries in 'display-monitor-attributes-list' (and adding them looks
>>> non-trivial, unless we go for 'Monitor-1', Monitor-2' etc.)
>>
>> Are there other NS-specific attributes that could provide
>> a clear reference to a specific monitor?  Maybe ‘geometry’
>> could be used to deduce a relative arrangement of monitors?
>
> I guess it could. Or we could fake up a monitor name on those systems
> where ns_screen_name doesnʼt work.

Since on Windows 'display-monitor-attributes-list' returns such
fake monitor names:

  \\.\DISPLAY1
  \\.\DISPLAY2

on macOS it could return something like that or generate fake names
from geometry like "1920x1080+0+0", "2560x1440+1920+16".

bug#34516: Multi-monitor frame sets

[Robert Pluim]

Juri Linkov <juri@linkov.net> writes:

>>>> I donʼt mind it, but it won't work on macOS, since thereʼs no 'name
>>>> entries in 'display-monitor-attributes-list' (and adding them looks
>>>> non-trivial, unless we go for 'Monitor-1', Monitor-2' etc.)
>>>
>>> Are there other NS-specific attributes that could provide
>>> a clear reference to a specific monitor?  Maybe ‘geometry’
>>> could be used to deduce a relative arrangement of monitors?
>>
>> I guess it could. Or we could fake up a monitor name on those systems
>> where ns_screen_name doesnʼt work.
>
> Since on Windows 'display-monitor-attributes-list' returns such
> fake monitor names:
>
>   \\.\DISPLAY1
>   \\.\DISPLAY2
>
> on macOS it could return something like that or generate fake names
> from geometry like "1920x1080+0+0", "2560x1440+1920+16".

I often have two identical monitors attached, so that would be
confusing :-)

Something like this (assuming nobody every connects more than 9
monitors to the same system).

diff --git a/src/nsfns.m b/src/nsfns.m
index edcdb988f7..91ab17032c 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -2698,6 +2698,12 @@ and GNUstep implementations ("distributor-specific release
 
 #ifdef NS_IMPL_COCOA
       m->name = ns_screen_name (did);
+      if (m->name == NULL)      /* Fallback value.  */
+        {
+          char name[9];
+          snprintf (name, sizeof(name), "DISPLAY%1d", i+1);
+          m->name = xstrdup (name);
+        }
 
       {
         CGSize mms = CGDisplayScreenSize (did);

bug#34516: Multi-monitor frame sets

[Juri Linkov]

>> Since on Windows 'display-monitor-attributes-list' returns such
>> fake monitor names:
>>
>>   \\.\DISPLAY1
>>   \\.\DISPLAY2
>>
>> on macOS it could return something like that or generate fake names
>> from geometry like "1920x1080+0+0", "2560x1440+1920+16".
>
> I often have two identical monitors attached, so that would be
> confusing :-)
>
> Something like this (assuming nobody every connects more than 9
> monitors to the same system).

I hope at least the primary monitor always comes first in the list.

bug#34516: Multi-monitor frame sets

[Andy Moreton]

On Sun 24 Feb 2019, Juri Linkov wrote:

>>> Since on Windows 'display-monitor-attributes-list' returns such
>>> fake monitor names:
>>>
>>>   \\.\DISPLAY1
>>>   \\.\DISPLAY2
>>>
>>> on macOS it could return something like that or generate fake names
>>> from geometry like "1920x1080+0+0", "2560x1440+1920+16".
>>
>> I often have two identical monitors attached, so that would be
>> confusing :-)
>>
>> Something like this (assuming nobody every connects more than 9
>> monitors to the same system).
>
> I hope at least the primary monitor always comes first in the list.

The `display-monitor-attributes-list' docstring states:

"Return a list of physical monitor attributes on DISPLAY.
DISPLAY can be a display name, a terminal name, or a frame.
If DISPLAY is omitted or nil, it defaults to the selected frame’s display.
Each element of the list represents the attributes of a physical
monitor.  The first element corresponds to the primary monitor."
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why are you still guessing, instead of reading the documentation ?

    AndyM

bug#34516: Multi-monitor frame sets

[Juri Linkov]

>>>> Since on Windows 'display-monitor-attributes-list' returns such
>>>> fake monitor names:
>>>>
>>>>   \\.\DISPLAY1
>>>>   \\.\DISPLAY2
>>>>
>>>> on macOS it could return something like that or generate fake names
>>>> from geometry like "1920x1080+0+0", "2560x1440+1920+16".
>>>
>>> I often have two identical monitors attached, so that would be
>>> confusing :-)
>>>
>>> Something like this (assuming nobody every connects more than 9
>>> monitors to the same system).
>>
>> I hope at least the primary monitor always comes first in the list.
>
> The `display-monitor-attributes-list' docstring states:
>
> "Return a list of physical monitor attributes on DISPLAY.
> DISPLAY can be a display name, a terminal name, or a frame.
> If DISPLAY is omitted or nil, it defaults to the selected frame’s display.
> Each element of the list represents the attributes of a physical
> monitor.  The first element corresponds to the primary monitor."
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Why are you still guessing, instead of reading the documentation ?

Right, the documentation should be the ultimate source of truth.
So I committed the patch to master.

bug#34516: Multi-monitor frame sets

[Alan Third]

On Sun, Feb 24, 2019 at 01:56:31PM +0100, Robert Pluim wrote:
> Juri Linkov <juri@linkov.net> writes:
> 
> > Since on Windows 'display-monitor-attributes-list' returns such
> > fake monitor names:
> >
> >   \\.\DISPLAY1
> >   \\.\DISPLAY2
> >
> > on macOS it could return something like that or generate fake names
> > from geometry like "1920x1080+0+0", "2560x1440+1920+16".
> 
> I often have two identical monitors attached, so that would be
> confusing :-)

I’m a bit late to this conversation, sorry.

I’d hope that the geometry would contain the origin of the monitor in
the overall screen ‘space’, so the primary monitor would have 0, 0,
and one to the left would have -1920, 0, or something. So it might not
be too confusing.

> Something like this (assuming nobody every connects more than 9
> monitors to the same system).
> 
> diff --git a/src/nsfns.m b/src/nsfns.m
> index edcdb988f7..91ab17032c 100644
> --- a/src/nsfns.m
> +++ b/src/nsfns.m
> @@ -2698,6 +2698,12 @@ and GNUstep implementations ("distributor-specific release
>  
>  #ifdef NS_IMPL_COCOA
>        m->name = ns_screen_name (did);
> +      if (m->name == NULL)      /* Fallback value.  */
> +        {
> +          char name[9];
> +          snprintf (name, sizeof(name), "DISPLAY%1d", i+1);
> +          m->name = xstrdup (name);
> +        }
>  
>        {
>          CGSize mms = CGDisplayScreenSize (did);

This appears to be the only place that ns_screen_name is called, so it
would probably be better to put this code in it and make
ns_screen_name return a name no matter what.

Also, it might be worth considering using the ‘did’ value instead of
‘i’. As far as I can tell it’s just a uint32_t, and should stay the
same as long as the system isn’t rebooted.
-- 
Alan Third

bug#34516: Multi-monitor frame sets

[Andy Moreton]

On Sat 02 Mar 2019, Alan Third wrote:

> On Sun, Feb 24, 2019 at 01:56:31PM +0100, Robert Pluim wrote:
>> Juri Linkov <juri@linkov.net> writes:
>> 
>> > Since on Windows 'display-monitor-attributes-list' returns such
>> > fake monitor names:
>> >
>> >   \\.\DISPLAY1
>> >   \\.\DISPLAY2

These names are *not* fake: they are the name of the underlying device
that represents the monitor. 

>> > on macOS it could return something like that or generate fake names
>> > from geometry like "1920x1080+0+0", "2560x1440+1920+16".

It would be more usefulr to use the underlying device name, like on other
platforms.

> I’m a bit late to this conversation, sorry.
>
> I’d hope that the geometry would contain the origin of the monitor in
> the overall screen ‘space’, so the primary monitor would have 0, 0,
> and one to the left would have -1920, 0, or something. So it might not
> be too confusing.

Yes, that is exactly how it works: the geometry shows where the monitor
is positioned in the overall coordinate system, and the workspace shows
the area on that monitor that is available to display frames (i.e. not
occupied by system tray toolbar, dock etc).

>> Something like this (assuming nobody every connects more than 9
>> monitors to the same system).

Not a sound assumption: why add an arbitrary limitation when there is no
need to ? Allow an arbitrary number of monitors, since there is no
reason to restrict it.

>> 
>> diff --git a/src/nsfns.m b/src/nsfns.m
>> index edcdb988f7..91ab17032c 100644
>> --- a/src/nsfns.m
>> +++ b/src/nsfns.m
>> @@ -2698,6 +2698,12 @@ and GNUstep implementations ("distributor-specific release
>>  
>>  #ifdef NS_IMPL_COCOA
>>        m->name = ns_screen_name (did);
>> +      if (m->name == NULL)      /* Fallback value.  */
>> +        {
>> +          char name[9];
>> +          snprintf (name, sizeof(name), "DISPLAY%1d", i+1);
>> +          m->name = xstrdup (name);
>> +        }
>>  
>>        {
>>          CGSize mms = CGDisplayScreenSize (did);
>
> This appears to be the only place that ns_screen_name is called, so it
> would probably be better to put this code in it and make
> ns_screen_name return a name no matter what.
>
> Also, it might be worth considering using the ‘did’ value instead of
> ‘i’. As far as I can tell it’s just a uint32_t, and should stay the
> same as long as the system isn’t rebooted.

Is the did value reused if monitors are dynamically plugged and
unplugged ? This may happen when using a laptop with docking
stations and external monitors.

    AndyM

bug#34516: Multi-monitor frame sets

[Alan Third]

On Sat, Mar 02, 2019 at 11:57:35PM +0000, Andy Moreton wrote:
> On Sat 02 Mar 2019, Alan Third wrote:
> 
> > On Sun, Feb 24, 2019 at 01:56:31PM +0100, Robert Pluim wrote:
> >> Juri Linkov <juri@linkov.net> writes:
> >> 
> >> > on macOS it could return something like that or generate fake names
> >> > from geometry like "1920x1080+0+0", "2560x1440+1920+16".
> 
> It would be more usefulr to use the underlying device name, like on other
> platforms.

It doesn’t look like macOS gives displays any sort of human readable
name. The closest I can find is the monitor’s make and model, which
appears to be lifted directly from the device driver. I expect if you
have two identical monitors then it will be the same for both.

> > Also, it might be worth considering using the ‘did’ value instead of
> > ‘i’. As far as I can tell it’s just a uint32_t, and should stay the
> > same as long as the system isn’t rebooted.
> 
> Is the did value reused if monitors are dynamically plugged and
> unplugged ? This may happen when using a laptop with docking
> stations and external monitors.

The documentation implies it may remain the same for the same monitor,
but then again, maybe not. It’s not very clear.

It shouldn’t be the same for two different monitors, though.
-- 
Alan Third

bug#34516: Multi-monitor frame sets

[Robert Pluim]

Alan Third <alan@idiocy.org> writes:

> On Sat, Mar 02, 2019 at 11:57:35PM +0000, Andy Moreton wrote:
>> On Sat 02 Mar 2019, Alan Third wrote:
>> 
>> > On Sun, Feb 24, 2019 at 01:56:31PM +0100, Robert Pluim wrote:
>> >> Juri Linkov <juri@linkov.net> writes:
>> >> 
>> >> > on macOS it could return something like that or generate fake names
>> >> > from geometry like "1920x1080+0+0", "2560x1440+1920+16".
>> 
>> It would be more usefulr to use the underlying device name, like on other
>> platforms.
>
> It doesn’t look like macOS gives displays any sort of human readable
> name. The closest I can find is the monitor’s make and model, which
> appears to be lifted directly from the device driver. I expect if you
> have two identical monitors then it will be the same for both.
>

At least in 'system preferences/display', when you have two identical monitors
attached, they're called something like 'DELL 1234X' and 'DELL 1234X
(2)' (I canʼt test that right now). If you can show me code on how to
get those names in 10.14, I can confirm. That would be better than
making up names.

>> > Also, it might be worth considering using the ‘did’ value instead of
>> > ‘i’. As far as I can tell it’s just a uint32_t, and should stay the
>> > same as long as the system isn’t rebooted.
>> 
>> Is the did value reused if monitors are dynamically plugged and
>> unplugged ? This may happen when using a laptop with docking
>> stations and external monitors.
>
> The documentation implies it may remain the same for the same monitor,
> but then again, maybe not. It’s not very clear.
>
> It shouldn’t be the same for two different monitors, though.

I can respin to use the did, if thereʼs no better alternative.

Robert

bug#34516: Multi-monitor frame sets

[Andy Moreton]

On Mon 04 Mar 2019, Robert Pluim wrote:

> Alan Third <alan@idiocy.org> writes:
>
>> On Sat, Mar 02, 2019 at 11:57:35PM +0000, Andy Moreton wrote:
>>> On Sat 02 Mar 2019, Alan Third wrote:
>>> 
>>> > On Sun, Feb 24, 2019 at 01:56:31PM +0100, Robert Pluim wrote:
>>> >> Juri Linkov <juri@linkov.net> writes:
>>> >> 
>>> >> > on macOS it could return something like that or generate fake names
>>> >> > from geometry like "1920x1080+0+0", "2560x1440+1920+16".
>>> 
>>> It would be more usefulr to use the underlying device name, like on other
>>> platforms.
>>
>> It doesn’t look like macOS gives displays any sort of human readable
>> name. The closest I can find is the monitor’s make and model, which
>> appears to be lifted directly from the device driver. I expect if you
>> have two identical monitors then it will be the same for both.
>>
>
> At least in 'system preferences/display', when you have two identical monitors
> attached, they're called something like 'DELL 1234X' and 'DELL 1234X
> (2)' (I canʼt test that right now). If you can show me code on how to
> get those names in 10.14, I can confirm. That would be better than
> making up names.

There are usually two different names involved: the name of the
file/device that represents the monitor, and a human-readable name for
the UI.

In Windows, the GUI settings/display describes the monitors as 1 and
2. In emacs, display-monitor-attributes-list reports the device
names \\.\DISPLAY1 and \\.\DISPLAY2 (you can see these device names
with the WinObj tool from SysInternals). Note that the device names do
not mention the make/model of the hardware.

For OSX, ioreg or the IoRegistryExplorer app show similar information
from the IO registry (a non-persistent database of IO device
information). I don't use a mac any more, so I don't know if these tools
are still available).

    AndyM

bug#34516: Multi-monitor frame sets

[Robert Pluim]

Andy Moreton <andrewjmoreton@gmail.com> writes:

>> At least in 'system preferences/display', when you have two identical monitors
>> attached, they're called something like 'DELL 1234X' and 'DELL 1234X
>> (2)' (I canʼt test that right now). If you can show me code on how to
>> get those names in 10.14, I can confirm. That would be better than
>> making up names.
>

So 'DELL 1234X (1)' and 'DELL 1234X (2)', where (1) is the primary
monitor.

> There are usually two different names involved: the name of the
> file/device that represents the monitor, and a human-readable name for
> the UI.
>
> In Windows, the GUI settings/display describes the monitors as 1 and
> 2. In emacs, display-monitor-attributes-list reports the device
> names \\.\DISPLAY1 and \\.\DISPLAY2 (you can see these device names
> with the WinObj tool from SysInternals). Note that the device names do
> not mention the make/model of the hardware.
>
> For OSX, ioreg or the IoRegistryExplorer app show similar information
> from the IO registry (a non-persistent database of IO device
> information). I don't use a mac any more, so I don't know if these tools
> are still available).

I donʼt know, but the code in ns_screen_name which appears to do
something similar does not work for me in 10.14

Iʼm not so sure about using the did, as someone suggested, since that
has a large value, eg here itʼs 724851601, Iʼd prefer to use a simple
index.

Robert

bug#34516: Multi-monitor frame sets

[Alan Third]

On Mon, Mar 04, 2019 at 05:10:59PM +0100, Robert Pluim wrote:
> Andy Moreton <andrewjmoreton@gmail.com> writes:
> 
> >> At least in 'system preferences/display', when you have two identical monitors
> >> attached, they're called something like 'DELL 1234X' and 'DELL 1234X
> >> (2)' (I canʼt test that right now). If you can show me code on how to
> >> get those names in 10.14, I can confirm. That would be better than
> >> making up names.
> >
> 
> So 'DELL 1234X (1)' and 'DELL 1234X (2)', where (1) is the primary
> monitor.
> 
> > There are usually two different names involved: the name of the
> > file/device that represents the monitor, and a human-readable name for
> > the UI.
> >
> > In Windows, the GUI settings/display describes the monitors as 1 and
> > 2. In emacs, display-monitor-attributes-list reports the device
> > names \\.\DISPLAY1 and \\.\DISPLAY2 (you can see these device names
> > with the WinObj tool from SysInternals). Note that the device names do
> > not mention the make/model of the hardware.
> >
> > For OSX, ioreg or the IoRegistryExplorer app show similar information
> > from the IO registry (a non-persistent database of IO device
> > information). I don't use a mac any more, so I don't know if these tools
> > are still available).
> 
> I donʼt know, but the code in ns_screen_name which appears to do
> something similar does not work for me in 10.14

Try this:

    ioreg -lw0 | grep IODisplayEDID | sed "/[^<]*</s///" | xxd -p -r | strings -6

and see if it returns usable information. If so then that’s what we
should be targeting in ns_screen_name.

I think the approach used in ns_screen_name must have been removed in
some version of macOS. I tried to modify it to find the information
returned by the above command, but it looks like there’s no direct way
to match up the DID number with IODisplayConnect, which is where
IODisplayEDID is stored.

I’d never heard of ioreg before yesterday, though, so if anyone knows
better I’d be happy to learn otherwise.

> Iʼm not so sure about using the did, as someone suggested, since that
> has a large value, eg here itʼs 724851601, Iʼd prefer to use a simple
> index.

I did think that might be an issue, the main advantage over the simple
index is that it shouldn’t change, whereas I don’t think the index is
guaranteed to be the same on any two consecutive calls.
-- 
Alan Third

bug#34516: Multi-monitor frame sets

[Robert Pluim]

Alan Third <alan@idiocy.org> writes:

>> I donʼt know, but the code in ns_screen_name which appears to do
>> something similar does not work for me in 10.14
>
> Try this:
>
>     ioreg -lw0 | grep IODisplayEDID | sed "/[^<]*</s///" | xxd -p -r | strings -6
>
> and see if it returns usable information. If so then that’s what we
> should be targeting in ns_screen_name.
>

When just using the built-in display, that gives me:
    Color LCD
    LP133WQ5-SJA2
    F0Y843102PCJ465AT

I can run the same test tomorrow when Iʼm by my external screens
again. Only the first line here is remotely intelligible, none of them
are displayed by macOS as far as I know.

> I think the approach used in ns_screen_name must have been removed in
> some version of macOS. I tried to modify it to find the information
> returned by the above command, but it looks like there’s no direct way
> to match up the DID number with IODisplayConnect, which is where
> IODisplayEDID is stored.
>
> I’d never heard of ioreg before yesterday, though, so if anyone knows
> better I’d be happy to learn otherwise.
>
>> Iʼm not so sure about using the did, as someone suggested, since that
>> has a large value, eg here itʼs 724851601, Iʼd prefer to use a simple
>> index.
>
> I did think that might be an issue, the main advantage over the simple
> index is that it shouldn’t change, whereas I don’t think the index is
> guaranteed to be the same on any two consecutive calls.

ns-display-monitor-attributes-list assumes that the first monitor has
index '0', so having that change would be surprising.

Robert

bug#34516: Multi-monitor frame sets

[Juri Linkov]

> I can run the same test tomorrow when Iʼm by my external screens
> again. Only the first line here is remotely intelligible, none of them
> are displayed by macOS as far as I know.

Did you have a chance to run the test?

Meanwhile, I pushed the fix based on your recommendations on emacs-devel.
Feel free to improve it if your test reveals a problem.

bug#34516: Multi-monitor frame sets

[Robert Pluim]

>>>>> On Tue, 19 Mar 2019 23:33:30 +0200, Juri Linkov <juri@linkov.net> said:

    >> I can run the same test tomorrow when Iʼm by my external
    >> screens again. Only the first line here is remotely
    >> intelligible, none of them are displayed by macOS as far as I
    >> know.

    Juri> Did you have a chance to run the test?

I did, but I forgot to send the results:

--begin--
q8-@X,E
JC9H65BD0ZLS
DELL P2714H

q8-@X,E
JC9H65BD1BHS
DELL P2714H
--end--

Weʼd need to extract that 'DELL' bit, and check if we have other
monitors with the same description string so we can add a suffix.

    Juri> Meanwhile, I pushed the fix based on your recommendations on
    Juri> emacs-devel.  Feel free to improve it if your test reveals a
    Juri> problem.

It works fine for me. Of course, now that Iʼm using it, Iʼd like a
'make-frame-on-current-monitor' :-) I guess I can iterate over the
frames elements of 'display-monitor-attributes-list', unless thereʼs a
'what monitor is this frame on' primitive.

Robert

bug#34516: Multi-monitor frame sets

[Robert Pluim]

>>>>> On Tue, 26 Mar 2019 08:24:56 +0100, Robert Pluim <rpluim@gmail.com> said:
    Robert> It works fine for me. Of course, now that Iʼm using it,
    Robert> Iʼd like a 'make-frame-on-current-monitor' :-) I guess I
    Robert> can iterate over the frames elements of
    Robert> 'display-monitor-attributes-list', unless thereʼs a 'what
    Robert> monitor is this frame on' primitive.

D'oh. 'frame-monitor-attributes'.

Robert

bug#34516: Multi-monitor frame sets

[Juri Linkov]

>     Robert> It works fine for me. Of course, now that Iʼm using it,
>     Robert> Iʼd like a 'make-frame-on-current-monitor' :-) I guess I
>     Robert> can iterate over the frames elements of
>     Robert> 'display-monitor-attributes-list', unless thereʼs a 'what
>     Robert> monitor is this frame on' primitive.
>
> D'oh. 'frame-monitor-attributes'.

Thanks for the hint.  Now I added the default value to
make-frame-on-monitor, so for the current monitor you can just do:
M-x make-frame-on-monitor RET RET

bug#34516: Multi-monitor frame sets

[Robert Pluim]

>>>>> On Wed, 27 Mar 2019 23:46:57 +0200, Juri Linkov <juri@linkov.net> said:

    Robert> It works fine for me. Of course, now that Iʼm using it,
    Robert> Iʼd like a 'make-frame-on-current-monitor' :-) I guess I
    Robert> can iterate over the frames elements of
    Robert> 'display-monitor-attributes-list', unless thereʼs a 'what
    Robert> monitor is this frame on' primitive.
    >> 
    >> D'oh. 'frame-monitor-attributes'.

    Juri> Thanks for the hint.  Now I added the default value to
    Juri> make-frame-on-monitor, so for the current monitor you can
    Juri> just do: M-x make-frame-on-monitor RET RET

Thanks for that. I guess we can close the bug, if it isnʼt closed
already.

Robert

bug#34516: Multi-monitor frame sets

[Juri Linkov]

>     Juri> Thanks for the hint.  Now I added the default value to
>     Juri> make-frame-on-monitor, so for the current monitor you can
>     Juri> just do: M-x make-frame-on-monitor RET RET
>
> Thanks for that. I guess we can close the bug, if it isnʼt closed
> already.

But what about your implementation of monitor names for macOS?

bug#34516: Multi-monitor frame sets

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 17 Feb 2019 21:34:19 +0200
> 
> Shouldn't frame.el provide a command like make-frame-on-display,
> but to make a frame on the specified monitor instead of display?
> 
> Isn't the following patch the right way to do this?
> (It also adds completion for the existing command):

What kind of list does display-monitor-attributes-list return on your
system, and how can you tell which part there refers to what physical
monitor?

bug#34516: Multi-monitor frame sets

[Juri Linkov]

>> Shouldn't frame.el provide a command like make-frame-on-display,
>> but to make a frame on the specified monitor instead of display?
>> 
>> Isn't the following patch the right way to do this?
>> (It also adds completion for the existing command):
>
> What kind of list does display-monitor-attributes-list return on your
> system, and how can you tell which part there refers to what physical
> monitor?

It returns a list with such meaningless monitor names as “LVDS”, “eDP-1”, “DP-2-2”,
etc. that don't help to refer to a physical monitor.  However, I noticed that
the only attribute that could help is ‘geometry’ in the form of (X Y WIDTH HEIGHT),
e.g. when two adjacent monitors have such geometry attributes:

  (geometry    0  0 1920 1080)
  (geometry 1920 16 2560 1440)

the right edge of the first monitor ends (1920px) is where the left edge
of the second monitor begins.  Based on this guess I tried to deduce
a relative placement of new frames, but maybe I'm wrong.

bug#34516: Multi-monitor frame sets

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 34516@debbugs.gnu.org
> Date: Mon, 18 Feb 2019 23:16:01 +0200
> 
> > What kind of list does display-monitor-attributes-list return on your
> > system, and how can you tell which part there refers to what physical
> > monitor?
> 
> It returns a list with such meaningless monitor names as “LVDS”, “eDP-1”, “DP-2-2”,
> etc. that don't help to refer to a physical monitor.  However, I noticed that
> the only attribute that could help is ‘geometry’ in the form of (X Y WIDTH HEIGHT),
> e.g. when two adjacent monitors have such geometry attributes:
> 
>   (geometry    0  0 1920 1080)
>   (geometry 1920 16 2560 1440)
> 
> the right edge of the first monitor ends (1920px) is where the left edge
> of the second monitor begins.  Based on this guess I tried to deduce
> a relative placement of new frames, but maybe I'm wrong.

Does the proposed function sound useful, given these issues?

bug#34516: Multi-monitor frame sets

[Juri Linkov]

>> > What kind of list does display-monitor-attributes-list return on your
>> > system, and how can you tell which part there refers to what physical
>> > monitor?
>> 
>> It returns a list with such meaningless monitor names as “LVDS”, “eDP-1”, “DP-2-2”,
>> etc. that don't help to refer to a physical monitor.  However, I noticed that
>> the only attribute that could help is ‘geometry’ in the form of (X Y WIDTH HEIGHT),
>> e.g. when two adjacent monitors have such geometry attributes:
>> 
>>   (geometry    0  0 1920 1080)
>>   (geometry 1920 16 2560 1440)
>> 
>> the right edge of the first monitor ends (1920px) is where the left edge
>> of the second monitor begins.  Based on this guess I tried to deduce
>> a relative placement of new frames, but maybe I'm wrong.
>
> Does the proposed function sound useful, given these issues?

The proposed function tries to provide the right geometry for
‘make-frame’, i.e. the geometry of the selected monitor, but I see
that it doesn't always makes a new frame on the specified monitor.
Also I don't understand the logic how currently ‘make-frame’ decides
on which monitor to make a new frame.

bug#34516: Multi-monitor frame sets

[Andy Moreton]

On Mon 18 Feb 2019, Juri Linkov wrote:

>>> Shouldn't frame.el provide a command like make-frame-on-display,
>>> but to make a frame on the specified monitor instead of display?
>>> 
>>> Isn't the following patch the right way to do this?
>>> (It also adds completion for the existing command):
>>
>> What kind of list does display-monitor-attributes-list return on your
>> system, and how can you tell which part there refers to what physical
>> monitor?
>
> It returns a list with such meaningless monitor names as “LVDS”, “eDP-1”, “DP-2-2”,
> etc. that don't help to refer to a physical monitor.

Those names are not meaningless, it is just that you do not find them
helpful. The names describe the hardware port used to attach the
monitor:

  https://en.wikipedia.org/wiki/Low-voltage_differential_signaling
  https://en.wikipedia.org/wiki/DisplayPort
  https://en.wikipedia.org/wiki/DisplayPort#eDP

>  However, I noticed that the only attribute that could help is
> ‘geometry’ in the form of (X Y WIDTH HEIGHT), e.g. when two adjacent
> monitors have such geometry attributes:
>
>   (geometry    0  0 1920 1080)
>   (geometry 1920 16 2560 1440)
>
> the right edge of the first monitor ends (1920px) is where the left edge
> of the second monitor begins.  Based on this guess I tried to deduce
> a relative placement of new frames, but maybe I'm wrong.

Why guess ? Read the documentation for `display-monitor-attributes-list'
which describes the meaning of the list elements in great detail.

Note that you will need to take note of the `workarea' element of the
list which describes the usuable space on a given monitor (which
excludes space for toolbars etc that are not available to display a
frame).

    AndyM

bug#34516: Multi-monitor frame sets

[Juri Linkov]

> Why guess ? Read the documentation for `display-monitor-attributes-list'
> which describes the meaning of the list elements in great detail.
>
> Note that you will need to take note of the `workarea' element of the
> list which describes the usuable space on a given monitor (which
> excludes space for toolbars etc that are not available to display a
> frame).

Thanks for the information.  Do you think it's possible to use
the list elements from `display-monitor-attributes-list'
to unambiguously select a monitor where to make a new frame?

bug#34516: Multi-monitor frame sets

[Andy Moreton]

On Tue 19 Feb 2019, Juri Linkov wrote:

>> Why guess ? Read the documentation for `display-monitor-attributes-list'
>> which describes the meaning of the list elements in great detail.
>>
>> Note that you will need to take note of the `workarea' element of the
>> list which describes the usuable space on a given monitor (which
>> excludes space for toolbars etc that are not available to display a
>> frame).
>
> Thanks for the information.  Do you think it's possible to use
> the list elements from `display-monitor-attributes-list'
> to unambiguously select a monitor where to make a new frame?

Yes. The list describes all monitors available for displaying frames, so
any new frame you wish to create must be shown (at least partially) on
one of those monitors.

The monitors may have different sizes, and be physically arranged in
fairly arbitrary ways. For example, on Windows (from bug#21173):

  +----------+
  |          |
  | DISPLAY2 |
  |          |+----------+
  +----------+|          |
              | DISPLAY1 |
              | (primary)|
              +----------+

  (display-monitor-attributes-list)
  ;; ==>
  '(((geometry 0 0 1920 1080)
     (workarea 0 0 1920 1050)
     (mm-size 677 381)
     (name . "\\\\.\\DISPLAY1")
     (frames ...))
    ((geometry -1680 -1050 1680 1050)
     (workarea -1680 -1050 1680 1050)
     (mm-size 593 370)
     (name . "\\\\.\\DISPLAY2")
     (frames ...)))

  ;; For a frame on DISPLAY2:
  (frame-parameter (window-frame) 'left) ;; ==>  (+ -1668)
  (frame-parameter (window-frame) 'top)  ;; ==>  (+ -1046)

bug#34516: Multi-monitor frame sets

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

>   (display-monitor-attributes-list)
>   ;; ==>
>   '(((geometry 0 0 1920 1080)
>      (workarea 0 0 1920 1050)
>      (mm-size 677 381)
>      (name . "\\\\.\\DISPLAY1")
>      (frames ...))
>     ((geometry -1680 -1050 1680 1050)
>      (workarea -1680 -1050 1680 1050)
>      (mm-size 593 370)
>      (name . "\\\\.\\DISPLAY2")
>      (frames ...)))

I see that ‘geometry’ is the same as ‘workarea’ on the second monitor,
but slightly different on the first one.  Mine are all the same,
so I don't know whether to use ‘geometry’ or ‘workarea’.

Meanwhile I found a mistake in my previous patch.  I assumed that
both pairs of attributes top/left and height/width for ‘make-frame’
are measured in pixels.  In fact, only top/left are in pixels,
whereas height/width are in text units.  So needed to wrap them
in ‘text-pixels’.  Now with this patch everything is fine:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: make-frame-on-monitor.2.patch --]
[-- Type: text/x-diff, Size: 2439 bytes --]

diff --git a/lisp/frame.el b/lisp/frame.el
index dc81302939..208748ef1d 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -644,9 +644,37 @@ window-system-for-display
 (defun make-frame-on-display (display &optional parameters)
   "Make a frame on display DISPLAY.
 The optional argument PARAMETERS specifies additional frame parameters."
-  (interactive "sMake frame on display: ")
+  (interactive (list (completing-read
+                      (format "Make frame on display: ")
+                      (delete-dups
+                       (mapcar (lambda (frame)
+                                 (frame-parameter frame 'display))
+                               (frame-list))))))
   (make-frame (cons (cons 'display display) parameters)))
 
+(defun make-frame-on-monitor (monitor &optional display parameters)
+  "Make a frame on monitor MONITOR.
+The optional argument PARAMETERS specifies additional frame parameters."
+  (interactive (list (completing-read
+                      (format "Make frame on monitor: ")
+                      (mapcar (lambda (a)
+                                (cdr (assq 'name a)))
+                              (display-monitor-attributes-list)))))
+  (let* ((monitor-geometry (car (delq nil (mapcar (lambda (a)
+                                                    (when (equal (cdr (assq 'name a)) monitor)
+                                                      (cdr (assq 'geometry a))))
+                                                  (display-monitor-attributes-list display)))))
+         (frame-geometry (x-parse-geometry (format "%dx%d+%d+%d"
+                                                   (nth 2 monitor-geometry)
+                                                   (nth 3 monitor-geometry)
+                                                   (nth 0 monitor-geometry)
+                                                   (nth 1 monitor-geometry))))
+         (frame-geometry-in-pixels `((top . ,(cdr (assq 'top frame-geometry)))
+                                     (left . ,(cdr (assq 'left frame-geometry)))
+                                     (height . (text-pixels . ,(cdr (assq 'height frame-geometry))))
+                                     (width . (text-pixels . ,(cdr (assq 'width frame-geometry)))))))
+    (make-frame (append frame-geometry-in-pixels parameters))))
+
 (declare-function x-close-connection "xfns.c" (terminal))
 
 (defun close-display-connection (display)

bug#34516: Multi-monitor frame sets

[Andy Moreton]

On Wed 20 Feb 2019, Juri Linkov wrote:

>>   (display-monitor-attributes-list)
>>   ;; ==>
>>   '(((geometry 0 0 1920 1080)
>>      (workarea 0 0 1920 1050)
>>      (mm-size 677 381)
>>      (name . "\\\\.\\DISPLAY1")
>>      (frames ...))
>>     ((geometry -1680 -1050 1680 1050)
>>      (workarea -1680 -1050 1680 1050)
>>      (mm-size 593 370)
>>      (name . "\\\\.\\DISPLAY2")
>>      (frames ...)))
>
> I see that ‘geometry’ is the same as ‘workarea’ on the second monitor,
> but slightly different on the first one.  Mine are all the same,
> so I don't know whether to use ‘geometry’ or ‘workarea’.

In the example above, the DISPLAY1 monitor has the Windows task bar
along the bottom edge (with auto-hide disabled), so space there is not
available for displaying emacs frames.

The Windows task bar is not displayed on the DISPLAY2 monitor in this
setup, so the DISPLAY2 workarea matches the geometry, as the whole
monitor can be used to display frames.

You should always use the workarea values for displaying emacs frames.

    AndyM

bug#34516: Multi-monitor frame sets

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]

> You should always use the workarea values for displaying emacs frames.

Ok, this patch uses the workarea instead:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: make-frame-on-monitor.3.patch --]
[-- Type: text/x-diff, Size: 2430 bytes --]

diff --git a/lisp/frame.el b/lisp/frame.el
index dc81302939..648944952f 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -644,9 +644,43 @@ window-system-for-display
 (defun make-frame-on-display (display &optional parameters)
   "Make a frame on display DISPLAY.
 The optional argument PARAMETERS specifies additional frame parameters."
-  (interactive "sMake frame on display: ")
+  (interactive (list (completing-read
+                      (format "Make frame on display: ")
+                      (delete-dups
+                       (mapcar (lambda (frame)
+                                 (frame-parameter frame 'display))
+                               (frame-list))))))
   (make-frame (cons (cons 'display display) parameters)))
 
+(defun make-frame-on-monitor (monitor &optional display parameters)
+  "Make a frame on monitor MONITOR.
+The optional argument DISPLAY can be a display name, and the optional
+argument PARAMETERS specifies additional frame parameters."
+  (interactive (list (completing-read
+                      (format "Make frame on monitor: ")
+                      (mapcar (lambda (a)
+                                (cdr (assq 'name a)))
+                              (display-monitor-attributes-list)))))
+  (let* ((monitor-geometry
+          (car (delq nil (mapcar (lambda (a)
+                                   (when (equal (cdr (assq 'name a)) monitor)
+                                     (cdr (assq 'workarea a))))
+                                 (display-monitor-attributes-list display)))))
+         (frame-geometry
+          (when monitor-geometry
+            (x-parse-geometry (format "%dx%d+%d+%d"
+                                      (nth 2 monitor-geometry)
+                                      (nth 3 monitor-geometry)
+                                      (nth 0 monitor-geometry)
+                                      (nth 1 monitor-geometry)))))
+         (frame-geometry-in-pixels
+          (when frame-geometry
+            `((top . ,(cdr (assq 'top frame-geometry)))
+              (left . ,(cdr (assq 'left frame-geometry)))
+              (height . (text-pixels . ,(cdr (assq 'height frame-geometry))))
+              (width . (text-pixels . ,(cdr (assq 'width frame-geometry))))))))
+    (make-frame (append frame-geometry-in-pixels parameters))))
+
 (declare-function x-close-connection "xfns.c" (terminal))
 
 (defun close-display-connection (display)

bug#34516: Multi-monitor frame sets

[martin rudalics]

 >> You should always use the workarea values for displaying emacs frames.

Much easier said than done.

 > Ok, this patch uses the workarea instead:

AFAICT, the workarea may "move" from one display to another.  So to be
on the safe side, code should always assume the presence of a workarea
even when there's none at the very moment.  But I have no idea whether
the workarea size and position may change when moving from one display
to another.

martin

bug#34516: Multi-monitor frame sets

[Juri Linkov]

>>> You should always use the workarea values for displaying emacs frames.
>
> Much easier said than done.
>
>> Ok, this patch uses the workarea instead:
>
> AFAICT, the workarea may "move" from one display to another.  So to be
> on the safe side, code should always assume the presence of a workarea
> even when there's none at the very moment.  But I have no idea whether
> the workarea size and position may change when moving from one display
> to another.

Then geometry is a safer option?

bug#34516: Multi-monitor frame sets

[Andy Moreton]

On Sun 24 Feb 2019, martin rudalics wrote:

>>> You should always use the workarea values for displaying emacs frames.
>
> Much easier said than done.
>
>> Ok, this patch uses the workarea instead:
>
> AFAICT, the workarea may "move" from one display to another.  So to be
> on the safe side, code should always assume the presence of a workarea
> even when there's none at the very moment.  But I have no idea whether
> the workarea size and position may change when moving from one display
> to another.

Please explain what you mean here with an example, as what you have
written makes no sense.

    AndyM

bug#34516: Multi-monitor frame sets

[martin rudalics]

 > Please explain what you mean here with an example, as what you have
 > written makes no sense.

Since I don't use multiple monitors it might not make sense indeed.
AFAIK usually only the primary monitor shows a taskbar, dock, or
panel.  Whether these can be shown on or moved to secondary monitors
is system dependent.  Hence IMO showing a frame on a secondary monitor
should pessimistically assume that a non-workarea object can appear
there even if 'display-monitor-attributes-list' says otherwise.  If
you are sure that this may not happen, just disregard what I said.

martin

bug#34516: Multi-monitor frame sets

[Andy Moreton]

On Mon 25 Feb 2019, martin rudalics wrote:

>> Please explain what you mean here with an example, as what you have
>> written makes no sense.
>
> Since I don't use multiple monitors it might not make sense indeed.
> AFAIK usually only the primary monitor shows a taskbar, dock, or
> panel.  Whether these can be shown on or moved to secondary monitors
> is system dependent.  Hence IMO showing a frame on a secondary monitor
> should pessimistically assume that a non-workarea object can appear
> there even if 'display-monitor-attributes-list' says otherwise.  If
> you are sure that this may not happen, just disregard what I said.

The workarea should always be the same size or smaller than the geometry
on each monitor, and this information (while system dependent) should
always be accurate when display-monitor-attributes-list is called.

However, it is entirely possible that the user reconfigures the taskbar,
dock panel etc. between a call to display-monitor-attributes-list and
using the information it returns.

   AndyM

bug#34516: Multi-monitor frame sets

[Andy Moreton]

On Mon 04 Mar 2019, Alan Third wrote:

> On Mon, Mar 04, 2019 at 05:10:59PM +0100, Robert Pluim wrote:
>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>> 
>> >> At least in 'system preferences/display', when you have two identical monitors
>> >> attached, they're called something like 'DELL 1234X' and 'DELL 1234X
>> >> (2)' (I canʼt test that right now). If you can show me code on how to
>> >> get those names in 10.14, I can confirm. That would be better than
>> >> making up names.
>> >
>> 
>> So 'DELL 1234X (1)' and 'DELL 1234X (2)', where (1) is the primary
>> monitor.
>> 
>> > There are usually two different names involved: the name of the
>> > file/device that represents the monitor, and a human-readable name for
>> > the UI.
>> >
>> > In Windows, the GUI settings/display describes the monitors as 1 and
>> > 2. In emacs, display-monitor-attributes-list reports the device
>> > names \\.\DISPLAY1 and \\.\DISPLAY2 (you can see these device names
>> > with the WinObj tool from SysInternals). Note that the device names do
>> > not mention the make/model of the hardware.
>> >
>> > For OSX, ioreg or the IoRegistryExplorer app show similar information
>> > from the IO registry (a non-persistent database of IO device
>> > information). I don't use a mac any more, so I don't know if these tools
>> > are still available).
>> 
>> I donʼt know, but the code in ns_screen_name which appears to do
>> something similar does not work for me in 10.14
>
> Try this:
>
>     ioreg -lw0 | grep IODisplayEDID | sed "/[^<]*</s///" | xxd -p -r | strings -6
>
> and see if it returns usable information. If so then that’s what we
> should be targeting in ns_screen_name.
>
> I think the approach used in ns_screen_name must have been removed in
> some version of macOS. I tried to modify it to find the information
> returned by the above command, but it looks like there’s no direct way
> to match up the DID number with IODisplayConnect, which is where
> IODisplayEDID is stored.

The #if tests in ns_screen_name suggest that the old method is no longer
available in OSX 10.9 and later.

From a quick web search, GLFW (a graphics library) seems to have
encountered this problem, and added a workaround in this commit:

https://github.com/glfw/glfw/commit/8101d7a7b67fc3414769b25944dc7c02b58d53d0

The patch matches on "IODisplayConnect" instances and then iterates over
the collection checking that the vendor ID and product ID match those
values looked up from the DID number.

A similar approach should help to solve this problem.

    AndyM

bug#34516: Multi-monitor frame sets

[Robert Pluim]

>>>>> On Thu, 28 Mar 2019 23:57:43 +0200, Juri Linkov <juri@linkov.net> said:

    Juri> Thanks for the hint.  Now I added the default value to
    Juri> make-frame-on-monitor, so for the current monitor you can
    Juri> just do: M-x make-frame-on-monitor RET RET
    >> 
    >> Thanks for that. I guess we can close the bug, if it isnʼt
    >> closed already.

    Juri> But what about your implementation of monitor names for
    Juri> macOS?

The fake ones? I guess I can push that, unless we have a working way
to get the real ones. I havenʼt had a chance to look at the other
project suggested by someone on this thread, nor do I know what
license itʼs under. Current version below.

Robert

From abcc4431240f9a9b3b9d8a22b3acbdb30b28f7d4 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Thu, 28 Feb 2019 10:13:05 +0100
Subject: [PATCH] Provide a fallback monitor name on macOS
To: emacs-devel@gnu.org

The fix for Bug#34516 provides a way to make a frame on a specific
monitor.  It relies on monitor names being available, which is not the
case for recent versions of macOS, so provide fake ones of the form
Monitorx.

* src/nsfns.m (Fns_display_monitor_attributes_list): Provide a
fallback for the monitor name if the existing methods don't work.
---
 src/nsfns.m | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/src/nsfns.m b/src/nsfns.m
index ee7598a1c7..3c4d8c91f3 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -2587,6 +2587,12 @@ Frames are listed from topmost (first) to bottommost (last).  */)
 
 #ifdef NS_IMPL_COCOA
       m->name = ns_screen_name (did);
+      if (m->name == NULL)      /* Fallback value.  */
+        {
+          char name[28];
+          snprintf (name, sizeof(name), "Monitor%lu", i+1);
+          m->name = xstrdup (name);
+        }
 
       {
         CGSize mms = CGDisplayScreenSize (did);
-- 
2.21.0.196.g041f5ea1cf

bug#34516: Multi-monitor frame sets

[Juri Linkov]

>     Juri> But what about your implementation of monitor names for
>     Juri> macOS?
>
> The fake ones? I guess I can push that, unless we have a working way
> to get the real ones. I havenʼt had a chance to look at the other
> project suggested by someone on this thread, nor do I know what
> license itʼs under. Current version below.

I think better fake than none, when it produces consistent names
at least within one Emacs session.

bug#34516: Multi-monitor frame sets

[Robert Pluim]

>>>>> On Sat, 30 Mar 2019 23:47:51 +0200, Juri Linkov <juri@linkov.net> said:

    Juri> But what about your implementation of monitor names for
    Juri> macOS?
    >> 
    >> The fake ones? I guess I can push that, unless we have a
    >> working way to get the real ones. I havenʼt had a chance to
    >> look at the other project suggested by someone on this thread,
    >> nor do I know what license itʼs under. Current version below.

    Juri> I think better fake than none, when it produces consistent
    Juri> names at least within one Emacs session.

I think it should do, except if the user changes which monitor is the
primary one.

Robert