Re: How to get DISPLAY of emacsclient?

[Max Nikulin]

To avoid misunderstanding,
    emacsclient --display "$DISPLAY" --eval ...
solves the problem (on Linux). For me, reasons to continue the 
discussion is that Stefan considered changes in Emacs code and that some 
suggestions was oversimplified.

On 30/11/2022 09:44, Stefan Monnier wrote:
> chad [2022-11-29 19:41:11] wrote:
> > On Tue, Nov 29, 2022 at 1:11 PM Max Nikulin wrote:
> > > [...]
> > > Add to user notes content of X selection when emacs is started as
> > > daemong with no frames and the user prefers to avoid distraction due to
> > > creation of a new frame.
> > In general, you seem to assume that there's no way for emacs to create a
> > new X11 frame object without it being immediately visible to the user. In
> > my experience, that's only true in the limited subset of cases where the
> > user has chosen a window manager that enforces that choice.

No, I did not assume it, it the starting message I mentioned 
`server-select-display' that creates a hidden frame. I have not tested 
various window managers though, I hope it just works. I was aware of 
info "(elisp) Visibility of Frames" 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Visibility-of-Frames.html 
The problem is how to determine proper display from an expression passed 
to emacsclient --eval.

> `xclip.el` (from GNU ELPA) uses:

Interesting, I had an impression that the main reason to invoke 
xclip/pbcopy/etc from Emacs is an alternative MIME type (selection 
target), e.g. text/html in the case of https://github.com/jkitchin/ox-clip

>            (setq xclip--hidden-frame
>                  (make-frame-on-display (getenv "DISPLAY")

It is appropriate for Emacs compiled with no X11 support, but in 
general, when overridden by --display, it may cause connection to a 
wrong display. Another case
    DISPLAY= emacs --daemon --display :0

>                                         '((visibility . nil)
>                                           (user-position . t)
>                                           (left . 0)
>                                           (top . 0)
>                                           (no-other-frame . t))))))

I consider it as another argument that `x-open-connection' is not enough 
to get selection and a frame is required.

> I haven't heard of a problem with that yet, but it probably hasn't been
> widely tested (and it is specific to X11).

I would say that, accordingly to the code, it is specific to 
(eq xclip-method 'emacs), not to X11.

> > This is a fundamentally different case from "the user wants to use a
> > non-graphical X11-based mechanism that emacs normally doesn't enable until
> > emacs actually connects to a working X11 display"

I never expected getting selection without opening of an X connection. I 
think an X11 window (frame in Emacs parlance) is not strictly necessary, 
but I am quite happy with a hidden frame.

> server.el also does something similar to xclip-mode, tho with simpler
> code:

Despite server.el sets less frame properties, it skips creation a frame 
if another one already exists on the specified display. That is why I 
would not call its code simpler.

> This code has been used a lot more widely, but in many/most cases we end
> up making that frame visible soon after, so there might be cases where
> it is not 100% unobtrusive but users don't notice it.

I have not noticed any problem with this code (besides tightly 
encapsulated value of display), but I have tried only Linux.

chad [2022-11-29 19:41:11] wrote:
> On Tue, Nov 29, 2022 at 1:11 PM Max Nikulin wrote:
>
> > User connected to another machine through ssh (e.g. from a laptop to a
> > desktop). In this case DISPLAY is different for the client and for the
> > server process. (gui-get-selection) should be executed for client's DISPLAY.
>
> In the past, I have regularly seen both varieties of this: where the
> user was logged into two machines, with an emacs server running on one,
> X displays on both, and wanted a new emacs frame on either one,
> depending on circumstances. As near as I can tell, there is no "right"
> choice here; the user needs to (be able to) provide input on which
> display to use.

I agree with you in general but in the case of accessing selected text 
it is almost certainly display where emacsclient is called.

Such choice is a reason that I did not consider the --display option at 
first. Usually its purpose is solely to override "$DISPLAY" value 
without additional effects.