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