From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Max Nikulin Newsgroups: gmane.emacs.devel Subject: Re: How to get DISPLAY of emacsclient? Date: Tue, 29 Nov 2022 23:23:50 +0700 Message-ID: References: <973588ef-d931-47a0-66d3-f8d70d92bd57@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32715"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 29 19:10:40 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0543-0008J4-Ev for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Nov 2022 19:10:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p053W-0003dG-K9; Tue, 29 Nov 2022 13:10:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p03Ou-0006Js-8p for emacs-devel@gnu.org; Tue, 29 Nov 2022 11:24:04 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p03Os-0001sL-J9 for emacs-devel@gnu.org; Tue, 29 Nov 2022 11:24:04 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1p03Oo-0000Ah-3q for emacs-devel@gnu.org; Tue, 29 Nov 2022 17:23:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 23 X-Spam_score: 2.3 X-Spam_bar: ++ X-Spam_report: (2.3 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.258, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 29 Nov 2022 13:10:03 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300715 Archived-At: 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 -c", which creates a frame on the > specified display ; it is equivalent to "env 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 "'