bug#29713: 26.0; Provide completion for `make-frame-on-display'

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Drew Adams]

Subject line says it all.  Gather the displays using, say,
`x-display-list' and use them as completion candidates.

(I don't use X Window, so I won't have more to say about this.)



In GNU Emacs 26.0.90 (build 3, x86_64-w64-mingw32)
 of 2017-10-13
Repository revision: 906224eba147bdfc0514090064e8e8f53160f1d4
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Subject line says it all.  Gather the displays using, say,
> `x-display-list' and use them as completion candidates.
>
> (I don't use X Window, so I won't have more to say about this.)

It provided completion for me when I tried this (":1")...

Yup, fixed in 57d2f24005a earlier this year.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Juri Linkov]

>> Subject line says it all.  Gather the displays using, say,
>> `x-display-list' and use them as completion candidates.
>>
>> (I don't use X Window, so I won't have more to say about this.)
>
> It provided completion for me when I tried this (":1")...
>
> Yup, fixed in 57d2f24005a earlier this year.

Maybe it could use `x-display-list'.  But I don't know how portable it is.
Is `x-display-list' available on OSX and Windows?

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Drew Adams]

> >> Subject line says it all.  Gather the displays using, say,
> >> `x-display-list' and use them as completion candidates.
> >>
> >> (I don't use X Window, so I won't have more to say about this.)
> >
> > It provided completion for me when I tried this (":1")...
> > Yup, fixed in 57d2f24005a earlier this year.
> 
> Maybe it could use `x-display-list'.  But I don't know how portable it is.
> Is `x-display-list' available on OSX and Windows?

Yes, on Windows (10), `C-h f x-display-list':

---

x-display-list is a built-in function in 'C source code'.

(x-display-list)

Return the list of display names that Emacs has connections to.

---

And it returns this list: ("w32").

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Robert Pluim]

>>>>> On Sun, 14 Jul 2019 22:46:28 +0300, Juri Linkov <juri@linkov.net> said:

    >>> Subject line says it all.  Gather the displays using, say,
    >>> `x-display-list' and use them as completion candidates.
    >>> 
    >>> (I don't use X Window, so I won't have more to say about this.)
    >> 
    >> It provided completion for me when I tried this (":1")...
    >> 
    >> Yup, fixed in 57d2f24005a earlier this year.

    Juri> Maybe it could use `x-display-list'.  But I don't know how portable it is.
    Juri> Is `x-display-list' available on OSX and Windows?

Itʼs available on OSX.

Robert

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Juri Linkov]

>> Maybe it could use `x-display-list'.  But I don't know how portable it is.
>> Is `x-display-list' available on OSX and Windows?

Drew Adams wrote:

> Yes, on Windows (10), `C-h f x-display-list':

Robert Pluim wrote:

> Itʼs available on OSX.

Thanks to Drew and Robert, this is fixed now.

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Basil L. Contovounesios]

Juri Linkov <juri@linkov.net> writes:

>>> Subject line says it all.  Gather the displays using, say,
>>> `x-display-list' and use them as completion candidates.
>>> (I don't use X Window, so I won't have more to say about this.)
> Maybe it could use `x-display-list'.  But I don't know how portable it is.
> Is `x-display-list' available on OSX and Windows?

It's not available on --without-x builds:

0. ./src/emacs -Q
1. M-x toggle-debug-on-error RET
2. M-x make-frame-on-display RET
   Debugger entered--Lisp error: (void-function x-display-list)

What's TRT here?

  (interactive (list (completing-read
                      (format "Make frame on display: ")
                      (if (fboundp 'x-display-list)
                          (x-display-list)
                        (user-error "No connected displays found")))))

This will barf before make-frame is called, and pacifies the
byte-compiler warning about x-display-list not being known.

  (interactive (list (completing-read
                      (format "Make frame on display: ")
                      (and (fboundp 'x-display-list)
                           (x-display-list)))))

This will barf when make-frame is called, with e.g.:

  make-frame: Don’t know how to interpret display ""
  make-frame: Don’t know how to interpret display ":0"

And also pacifies the warning.

Any preferences or alternative suggestions?

Thanks,

-- 
Basil

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Date: Thu, 18 Mar 2021 14:02:00 +0000
> Cc: 29713@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> >>> Subject line says it all.  Gather the displays using, say,
> >>> `x-display-list' and use them as completion candidates.
> >>> (I don't use X Window, so I won't have more to say about this.)
> > Maybe it could use `x-display-list'.  But I don't know how portable it is.
> > Is `x-display-list' available on OSX and Windows?
> 
> It's not available on --without-x builds:
> 
> 0. ./src/emacs -Q
> 1. M-x toggle-debug-on-error RET
> 2. M-x make-frame-on-display RET
>    Debugger entered--Lisp error: (void-function x-display-list)
> 
> What's TRT here?

For which use case?

In a build --without-x asking about available displays makes no sense,
because such a build cannot possibly access any displays.  Right?

In a GUI session, the function is always available, although the list
it returns might disappoint w32 users...

>   (interactive (list (completing-read
>                       (format "Make frame on display: ")
>                       (if (fboundp 'x-display-list)
>                           (x-display-list)
>                         (user-error "No connected displays found")))))
> 
> This will barf before make-frame is called, and pacifies the
> byte-compiler warning about x-display-list not being known.
> 
>   (interactive (list (completing-read
>                       (format "Make frame on display: ")
>                       (and (fboundp 'x-display-list)
>                            (x-display-list)))))
> 
> This will barf when make-frame is called, with e.g.:
> 
>   make-frame: Don’t know how to interpret display ""
>   make-frame: Don’t know how to interpret display ":0"
> 
> And also pacifies the warning.
> 
> Any preferences or alternative suggestions?

make-frame-on-display should signal an error in non-GUI builds.

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Date: Thu, 18 Mar 2021 14:02:00 +0000
>> Cc: 29713@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
>> 
>> It's not available on --without-x builds:
>> 
>> 0. ./src/emacs -Q
>> 1. M-x toggle-debug-on-error RET
>> 2. M-x make-frame-on-display RET
>>    Debugger entered--Lisp error: (void-function x-display-list)
>> 
>> What's TRT here?
>
> For which use case?

That wherein a user unwittingly invokes M-x make-frame-on-display in a
non-GUI build.  It's a very minor issue, but I think it's better if the
error message alludes to this operation being unsupported, rather than
complaining that x-display-list is void.

> In a build --without-x asking about available displays makes no sense,
> because such a build cannot possibly access any displays.  Right?

Right (AFAIK).

> In a GUI session, the function is always available, although the list
> it returns might disappoint w32 users...

Is there a better option on w32?

>>   (interactive (list (completing-read
>>                       (format "Make frame on display: ")
>>                       (if (fboundp 'x-display-list)
>>                           (x-display-list)
>>                         (user-error "No connected displays found")))))
>> 
>> This will barf before make-frame is called, and pacifies the
>> byte-compiler warning about x-display-list not being known.
>> 
>>   (interactive (list (completing-read
>>                       (format "Make frame on display: ")
>>                       (and (fboundp 'x-display-list)
>>                            (x-display-list)))))
>> 
>> This will barf when make-frame is called, with e.g.:
>> 
>>   make-frame: Don’t know how to interpret display ""
>>   make-frame: Don’t know how to interpret display ":0"
>> 
>> And also pacifies the warning.
>> 
>> Any preferences or alternative suggestions?
>
> make-frame-on-display should signal an error in non-GUI builds.

Agreed, but are you sanctioning the first option above, or either
option, so long as some error is signalled?

Thanks,

-- 
Basil

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: juri@linkov.net,  29713@debbugs.gnu.org,  larsi@gnus.org
> Date: Thu, 18 Mar 2021 15:09:51 +0000
> 
> > In a GUI session, the function is always available, although the list
> > it returns might disappoint w32 users...
> 
> Is there a better option on w32?

The w32 build supports only one display.

> >>   (interactive (list (completing-read
> >>                       (format "Make frame on display: ")
> >>                       (if (fboundp 'x-display-list)
> >>                           (x-display-list)
> >>                         (user-error "No connected displays found")))))
> >> 
> >> This will barf before make-frame is called, and pacifies the
> >> byte-compiler warning about x-display-list not being known.
> >> 
> >>   (interactive (list (completing-read
> >>                       (format "Make frame on display: ")
> >>                       (and (fboundp 'x-display-list)
> >>                            (x-display-list)))))
> >> 
> >> This will barf when make-frame is called, with e.g.:
> >> 
> >>   make-frame: Don’t know how to interpret display ""
> >>   make-frame: Don’t know how to interpret display ":0"
> >> 
> >> And also pacifies the warning.
> >> 
> >> Any preferences or alternative suggestions?
> >
> > make-frame-on-display should signal an error in non-GUI builds.
> 
> Agreed, but are you sanctioning the first option above, or either
> option, so long as some error is signalled?

I'm not sure.  The wording of the messages sounds not the best to me.
It should ideally say something like "This Emacs build doesn't support
X displays".

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Juri Linkov]

>> Maybe it could use `x-display-list'.  But I don't know how portable it is.
>> Is `x-display-list' available on OSX and Windows?
>
> It's not available on --without-x builds:
>
> 0. ./src/emacs -Q
> 1. M-x toggle-debug-on-error RET
> 2. M-x make-frame-on-display RET
>    Debugger entered--Lisp error: (void-function x-display-list)
>
> What's TRT here?

Maybe fall back to previous implementation replaced by x-display-list
in 0746a9e275d, i.e.

  (if (fboundp 'x-display-list)
      (x-display-list)
    (delete-dups
     (mapcar (lambda (frame)
               (frame-parameter frame 'display))
             (frame-list))))

Does this fail on --without-x builds?

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Juri Linkov]

>>> Maybe it could use `x-display-list'.  But I don't know how portable it is.
>>> Is `x-display-list' available on OSX and Windows?
>>
>> It's not available on --without-x builds:
>>
>> 0. ./src/emacs -Q
>> 1. M-x toggle-debug-on-error RET
>> 2. M-x make-frame-on-display RET
>>    Debugger entered--Lisp error: (void-function x-display-list)
>>
>> What's TRT here?
>
> Maybe fall back to previous implementation replaced by x-display-list
> in 0746a9e275d, i.e.
>
>   (if (fboundp 'x-display-list)
>       (x-display-list)
>     (delete-dups
>      (mapcar (lambda (frame)
>                (frame-parameter frame 'display))
>              (frame-list))))

Or maybe better to fall back to 'make-frame'?
I.e. don't signal an error, don't ask a question,
just create a new frame on the current display.

So on --without-x builds, make-frame-on-display
could be like an alias to make-frame.

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Basil L. Contovounesios]

Juri Linkov <juri@linkov.net> writes:

> Maybe fall back to previous implementation replaced by x-display-list
> in 0746a9e275d, i.e.
>
>   (if (fboundp 'x-display-list)
>       (x-display-list)
>     (delete-dups
>      (mapcar (lambda (frame)
>                (frame-parameter frame 'display))
>              (frame-list))))
>
> Does this fail on --without-x builds?

No, but (frame-parameter frame 'display) is always nil, so you still get
practically the same error as with:

  (and (fboundp 'x-display-list)
       (x-display-list))

-- 
Basil

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Basil L. Contovounesios]

Juri Linkov <juri@linkov.net> writes:

>> Maybe fall back to previous implementation replaced by x-display-list
>> in 0746a9e275d, i.e.
>>
>>   (if (fboundp 'x-display-list)
>>       (x-display-list)
>>     (delete-dups
>>      (mapcar (lambda (frame)
>>                (frame-parameter frame 'display))
>>              (frame-list))))
>
> Or maybe better to fall back to 'make-frame'?
> I.e. don't signal an error, don't ask a question,
> just create a new frame on the current display.
>
> So on --without-x builds, make-frame-on-display
> could be like an alias to make-frame.

I have no strong preference between this option or just signalling an
error in the interactive spec.  What do others think?

Thanks,

-- 
Basil

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Date: Wed, 24 Mar 2021 21:59:42 +0000
> Cc: 29713@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
> 
> > Or maybe better to fall back to 'make-frame'?
> > I.e. don't signal an error, don't ask a question,
> > just create a new frame on the current display.
> >
> > So on --without-x builds, make-frame-on-display
> > could be like an alias to make-frame.
> 
> I have no strong preference between this option or just signalling an
> error in the interactive spec.  What do others think?

I think we should signal an error: the user will not get what they
want, so the user must be told.

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Juri Linkov]

>> > Or maybe better to fall back to 'make-frame'?
>> > I.e. don't signal an error, don't ask a question,
>> > just create a new frame on the current display.
>> >
>> > So on --without-x builds, make-frame-on-display
>> > could be like an alias to make-frame.
>>
>> I have no strong preference between this option or just signalling an
>> error in the interactive spec.  What do others think?
>
> I think we should signal an error: the user will not get what they
> want, so the user must be told.

I agree.

bug#29713: 26.0; Provide completion for `make-frame-on-display'

[Basil L. Contovounesios]

Juri Linkov <juri@linkov.net> writes:

>>> > Or maybe better to fall back to 'make-frame'?
>>> > I.e. don't signal an error, don't ask a question,
>>> > just create a new frame on the current display.
>>> >
>>> > So on --without-x builds, make-frame-on-display
>>> > could be like an alias to make-frame.
>>>
>>> I have no strong preference between this option or just signalling an
>>> error in the interactive spec.  What do others think?
>>
>> I think we should signal an error: the user will not get what they
>> want, so the user must be told.
>
> I agree.

Done:

Address some --without-x byte-compilation warnings
331ddd803a 2021-03-26 17:35:34 +0000
https://git.sv.gnu.org/cgit/emacs.git/commit/?id=331ddd803a72056d0f0c70e5a677e0d4a6300584

Thanks,

-- 
Basil