From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Adding with-editor to Emacs? Date: Sat, 02 Sep 2023 09:19:06 +0300 Message-ID: <8334zxayhx.fsf@gnu.org> References: <85msy98sni.fsf@elpa.gnu.org> <87r0nidkmt.fsf@bernoul.li> <83bkelc1p1.fsf@gnu.org> <87fs3xwzxm.fsf@bernoul.li> <837cp9bur7.fsf@gnu.org> <87a5u5wskw.fsf@bernoul.li> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33050"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, emacs-devel@gnu.org, rms@gnu.org To: Jonas Bernoulli Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 02 08:20:22 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 1qcJza-0008Pl-4h for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Sep 2023 08:20:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qcJyo-0000Fp-5O; Sat, 02 Sep 2023 02:19:34 -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 1qcJyk-0000EM-TZ for emacs-devel@gnu.org; Sat, 02 Sep 2023 02:19:31 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qcJyj-0007oS-A3; Sat, 02 Sep 2023 02:19:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=MlXyWIwnvC8eR/eBmsgMgxunnpWZ+5cmPpuw7+uquhE=; b=sdwt+8jWdYtW YrgelzrcCRKzndGhNvdx9yWdDCGgfIqMc801YA4VKtTb3FVZ0hdLCaQZ/Q0is3hnCUcjGVqgRbZWe sQUpO+TXnMdPKmjXugtKqXsLrdkeB6qZg4JYciD20zDDPOWupW71MoW0Ldx8xn7Itmh6kNB12bAHI c9ykWPjjZy/t+IGY6T0ZiUHs1HnoW9fA2XiiJaOmwt/fP6N8a1WayIT2mRzwel5OMvEv4i4JQLgpC 5TomFCPDO4OtAEyyYDi0cXyz6ZlG39yL70GnMj+N9+Mpq0ul7OzsnsjVhjcbMQQhsepm1g+WUxQi9 OFO4MhohhfQB2bt6YkdVFQ==; In-Reply-To: <87a5u5wskw.fsf@bernoul.li> (message from Jonas Bernoulli on Fri, 01 Sep 2023 22:23:43 +0200) 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:309850 Archived-At: > From: Jonas Bernoulli > Cc: stefankangas@gmail.com, emacs-devel@gnu.org, rms@gnu.org > Date: Fri, 01 Sep 2023 22:23:43 +0200 > > Eli Zaretskii writes: > > >> > 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. ... Then I guess you should describe all those atrocities in detail, so that we could perhaps devise ways of handling it. Also, since the client-server protocol doesn't change much, there's usually no need to insist on invoking the emacsclient that came with this particular Emacs, you can use any other. > > 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. What do you mean? the value of installation-directory is calculated internally by Emacs. > >> 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. In what ways does "the above" mean that emacsclient doesn't work OOTB? Do you mean that emacsclient is installed in a place that just typing "emacsclient RET" at the shell prompt fails to run it? If so, that's a broken installation, and Emacs shouldn't really try to fix that. Or do you mean something else? > 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. We need to understand better the problems which caused this. The usual fallback for (expand-file-name "emacsclient" invocation-directory) is (expand-file-name "emacsclient" (expand-file-name "../lib-src/" invocation-directory)) and if that also fails, just use "emacsclient", i.e. find some version of the client on PATH. If you are saying this doesn't work, either, then we need to understand why and in what cases, and then decide what, if anything, to do about that.