Re: How to get DISPLAY of emacsclient?

[Max Nikulin]

On 28/11/2022 03:36, Jim Porter wrote:
> Looking through the emacsclient.c code, I think this is intentional, and 
> if you want to do something like this, the above workaround is exactly 
> what you're supposed to do:
>
>       If the -c option is used (without -t) and no --display argument
>       is provided, try $DISPLAY.
>       Without the -c option, we used to set 'display' to $DISPLAY by
>       default, but this changed the default behavior and is sometimes
>       inconvenient.  So we force users to use "--display $DISPLAY" if
>       they want Emacs to connect to their current display.

Thank you, I have reread emacsclinet code and have realized that I did 
not expect such behavior. At first I missed that environment is sent to 
server only if -c option is specified and the DISPLAY environment may be 
ignored. I believed that display value is always received, but can not 
be obtained because it is assigned to a local variable. Actually it is 
not sent for simple eval.

It is not stressed in the manual that emacsclient uses the --display 
option and the DISPLAY environment in a rather unusual way in comparison 
to other X application. I considered --display option as a way to 
override $DISPLAY and nothing more.

    emacsclient --display "$DISPLAY" --eval ...

behaves as required despite it looks a bit strange. It reuses existing X 
connection or creates a new hidden frame. As a result X selection 
becomes available without additional function calls.

On 28/11/2022 08:19, Po Lu wrote:
> `x-open-connection' is your friend.

The problem was to determine DISPLAY argument for this function. 
Moreover it is not enough and (gui-get-selection) return nil if just 
`x-open-connection' is called from emacsclient. In this sense 
`server-select-display' is better, but it requires DISPLAY as well.

On 27/11/2022 23:12, Gregory Heytings wrote:
> there is no display involved.  If you create an emacsclient process with
> -c or -r, then in Elisp you can get the display on which the frame is
> displayed with (getenv "DISPLAY"), or (cdr (assq 'display
> (frame-parameters))).

I was seeking a way to avoid creation a visible frame and to call a 
function that does not work without X connection.

So I should thank Jim again for drawing my attention why the effect of 
the --display option is stronger than for the DISPLAY environment. This 
option indirectly solves the problem.