From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: Adding with-editor to Emacs? Date: Fri, 01 Sep 2023 22:23:43 +0200 Message-ID: <87a5u5wskw.fsf@bernoul.li> References: <85msy98sni.fsf@elpa.gnu.org> <87r0nidkmt.fsf@bernoul.li> <83bkelc1p1.fsf@gnu.org> <87fs3xwzxm.fsf@bernoul.li> <837cp9bur7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27997"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, emacs-devel@gnu.org, rms@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 02 07:53:02 2023 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 1qcJZ8-00071u-0Z for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Sep 2023 07:53:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qcJYO-00058T-JQ; Sat, 02 Sep 2023 01:52:16 -0400 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 1qcAgL-0003OC-3I for emacs-devel@gnu.org; Fri, 01 Sep 2023 16:23:53 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qcAgH-0002ta-TG; Fri, 01 Sep 2023 16:23:52 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id A24A2164BF; Fri, 1 Sep 2023 22:23:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from; s=sel2011a; t=1693599824; bh=uvOYwZ/NBZ7oXxsBpk6QnIMalDkSeX/ZkI/46hUCHG4=; b= iNkpqjfqxgPrceHDu3dr+G+mTOjMT0xIIMq+2wjyaWIwG208AkFm0G/+487LjLeA hat8fADciIQaYaJGvSRq5mFc+2lNVkMxS2sb5/Tq8nqYOc1fka9mrvmAZ3x38WTu fxqlezz0PNKuNqElKInUs64Rl/PPIo6+LMnMfqPeDQ8= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id GXUYvwooRtdb; Fri, 1 Sep 2023 22:23:44 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 33F91164B4; Fri, 1 Sep 2023 22:23:44 +0200 (CEST) In-Reply-To: <837cp9bur7.fsf@gnu.org> Received-SPF: pass client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 02 Sep 2023 01:52:14 -0400 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:309848 Archived-At: Eli Zaretskii writes: >> From: Jonas Bernoulli >> Cc: emacs-devel@gnu.org, rms@gnu.org >> Date: Fri, 01 Sep 2023 19:44:53 +0200 >> >> Eli Zaretskii writes: >> - It implements a "sleeping editor". This is a shell script, which >> outputs a request on stdout and then waits to be told to return. >> With-editor use a process filter too look for that output and when >> it sees it, it responds in a similar fashion to server.el. This >> is useful because makes it possible to do this over Tramp. (I >> believe this could also be done using regular emacsclient+server.el, >> but that is difficult to setup and a security risk if not done >> correctly. > > If we want a better/safer client-server connections for remote hosts, > it should be handled in Tramp, I think. Probably and it would be great if Tramp did handle that, but I don't even use Tramp except when users report that there is an issue when using Tramp with one of my packages. So I am not the right person to implement it there, but if Michael were to tackle this, then maybe I would have some insights that could be useful. Or not. >> - It provides some convenience functionality to use this from various >> shells running inside Emacs. > > Can you provide details? The above is too terse for me to understand > the functionality. Essentially what it does is "export EDITOR=emacsclient" without as if that line existed in the shells init file. When summarized like that, this is of course a bit of a silly feature -- users can just put that line in their init file instead. (Also I should point out that I did not actually want to add support for this, but got talked into it.) The reason why people wanted me to this is that simply using "emacsclient" as the value turned out not to be good enough. >> > Emacs knows very well where to find its corresponding emacsclient. >> >> I wasn't aware of that. How can I make use of that knowledge? I.e., >> is there a function that answers the question "what is the path of the >> emacsclient that was installed with this version of emacs"? > > When Emacs runs installed, emacsclient is in the same directory where > we install the Emacs binary, so emacsclient should be in > invocation-directory. "I have seen things you wouldn't believe..." I wish this was true, but unfortunately keep coming up with new and innovative ways of not doing that. The worst platform is macOS, but I also had to add a special case for Debian. Users or distributions may install emacs in a weird location, and then symlink emacs onto $PATH (but without doing the same for emacsclient). It is also possible to install multiple versions of emacs in the same directory and append version strings to the installed binaries. To select one of these versions a user/distribution may add a symlink named symlink in the same directory. One may or may not do the same for emacsclient. If emacsclient isn't a symlink, then an ancient emacsclient may still be leftover from an earlier manual installed that was not properly uninstalled. ... > If Emacs runs uninstalled, emacsclient is in ../lib-src/ relative to > invocation-directory. Whether Emacs runs installed or not is > determined by the value of installation-directory: if it's nil, Emacs > runs installed. ... and that too. > There could be a complication if the programs were renamed when > installed (see TRANSFORM in the top-level Makefile). When that > happens, emacsclient's name is also TRANSFORMed in the same way. You > can find out what was the actual name under which Emacs was invoked > from the value of invocation-name, and then apply the same TRANSFORM > to the name of emacsclient. > >> > Why is there a need for a separate library? >> >> I agree that there theoretically isn't a need for this library, but it >> turned out that just setting EDITOR=emacsclient in the environment of >> the sub process also doesn't cut it, because for many users (who never >> use emacsclient directly), would have to add some configuration to make >> it work. The core and original functionality provided by with-editor, >> is making the configuration unnecessary by using heuristics. > > Can you elaborate on the configuration that is needed? I always > thought that emacsclient worked for everybody OOTB. Sadly that isn't the case, see above. Normally these complications are the user's problem. They may not even use emacsclient. If they don't actively choose to use emacsclient, they will never know it is actually broken for them. If they try to use it and it doesn't work, they can decide whether it is worth trying to figure out to work around those mistakes. If they want to use it but cannot fix it for themselves, they can contact the people who packaged Emacs for them. For me the situation was different, I started with something like this in one of my packages, effectively forcing users to use "emacsclient": (let ((process-environment process-environment)) (setenv "EDITOR" (expand-file-name "emacsclient" invocation-directory)) (call-process "git" nil nil nil "commit")) Like you I assumed this was a solved problem. And then the "I cannot commit anymore" reports started pouring in. I decided to implement with-editor, and to once in a while add a new heuristic to detect the correct emacsclient, instead of having to support users 1on1 for evermore, to figure out how exactly emacsclient isn't located and/or named what it is supposed to be, in their particular case. >> > (I couldn't find the beginning of this discussion, so maybe I missed >> > some of the relevant context, in which case I apologize.) >> >> The text I quoted, was the very beginning of this discussion. > > Yes, but did RMS write anything that you haven't quoted? Except > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] and the signature? No, the text I quoted is all of it.