Re: How to get DISPLAY of emacsclient?

[Max Nikulin <manikulin@gmail.com>]

On 29/11/2022 01:19, Stefan Monnier wrote:
>> 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.
> 
> IIRC there is no good reason other than a historical accident (and the
> fact that there was no clear need for it) why the environment isn't sent
> in all cases.  IOW, we could change it without breaking
> backward compatibility, AFAIK.

I agree with Gregory that --eval often does not need display. Certainly 
there are enough cases when X connection is undesired. If a frame is not 
ensured then display value is inaccessible from elisp code even 
indirectly. That is why there is a little point in sending display 
without exposing it through a variable. I do not mind to have such 
variable though.

I think, the problem is that the --display option is overloaded as an 
interface familiar for X11 users. I have not tried other OSes, but the 
issue may be even more severe. I have an idea to mention "emacsclient 
--display ..." in the Org manual e,g, in info "(org) Protocols" and 
maybe in info "(org) Capture" sections
https://orgmode.org/manual/Protocols.html
https://orgmode.org/manual/Capture.html
I do not like too verbose details related to special display values for 
Windows and macOS.

Perhaps a boolean flag like --force-display would be easier to discover 
and --display DISPLAY may assume --force-display. I hope it will be 
easier to discover and its effect will be more clear.

At least I would consider changing of documentation:
info "(emacs) emacsclient Options"
https://www.gnu.org/software/emacs/manual/html_node/emacs/emacsclient-Options.html
"Ensure connection to the specified display (X11 or OS-specific). Notice 
that without this option the DISPLAY environment is used to create a new 
frame, but it is ignored for --eval expressions when frame-related 
options are omitted."
instead of current

> Tell Emacs to open the given files on the X display display (assuming
> there is more than one X display available)

I have no idea of a concise variant to replace emacsclient --help:

> Visit the file in the given display

On 29/11/2022 00:15, Gregory Heytings wrote:
> I still think this is an ill-posed problem, so here are a few additional
> thoughs, in case you find them useful.

I agree that it is not really common, but I see no reason why the 
following cases are ill-posed:

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.

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.

> 1. "emacsclient --eval '(+ 1 1)'" does NOT use a display: it is
> evaluated in the server process.  You can use '(getenv DISPLAY)' there,
> but it will not return any useful information, it will return the value
> of DISPLAY that was current when the Emacs daemon was created.

Sometimes (getenv "DISPLAY") gives wrong result and I tried to highlight 
it in my first message and above.

> 2. "emacsclient -c", which creates a frame on the display specified in
> the environment variable DISPLAY (if DISPLAY is unset, "emacsclient -c"
> is equivalent to "emacsclient -nw").

Terminal frame may still be associated with DISPLAY as well. The 
challenge is to get something useful from `gui-get-selection' (may be 
called by `org-capture') in the absence of a visible frame.

> 3. "emacsclient --display <DISPLAY> -c", which creates a frame on the
> specified display <DISPLAY>; it is equivalent to "env DISPLAY=<DISPLAY>
> emacsclient -c".

A subtle point is that the DISPLAY environment affects only -c while 
--display forces X11 connection even for --eval.

> If you want to know the value if the environment variable DISPLAY in
> case 1, the best way to do that is to explicitly include "$DISPLAY" in
> the form you evaluate, e.g. like this:

I saw that display value is sent as a part of environment and as a 
dedicated message. I had a hope that it is possible to access these 
values, so adding it once more inside --eval expression is redundant. I 
missed that it is sent *conditionally*.

> emacsclient --eval '(progn (setq display "'$DISPLAY'") (princ display))' 

Unfortunately it is unsafe way to pass external values to elisp. It is 
unlikely, but if accidentally DISPLAY is set to some value with spaces 
and various shell special characters then arbitrary commands may be 
executed unexpectedly. I hope, some day I will summarize a discussion 
with Jim as a feature request to support a kind of 
`command-line-args-left' in expressions passed from emacsclient.

Max Nikulin to emacs-orgmode. Re: Lazy load of org-protocol. Wed, 9 Feb 
2022 23:46:26 +0700. https://list.orgmode.org/su0r54$f42$1@ciao.gmane.io

Another pair of double quotes around $DISPLAY will deactivate shell 
special characters, but it is still necessary to escape double quotes 
and backslashes to keep elisp expression well formed. Consider

     DISPLAY=':0") (do-something-else) (ignore "'