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 19:44:53 +0200 Message-ID: <87fs3xwzxm.fsf@bernoul.li> References: <85msy98sni.fsf@elpa.gnu.org> <87r0nidkmt.fsf@bernoul.li> <83bkelc1p1.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="4049"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, rms@gnu.org To: Eli Zaretskii , Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 01 20:28:19 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 1qc8sU-0000tC-NI for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Sep 2023 20:28:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qc8ra-0002Z6-9b; Fri, 01 Sep 2023 14:27:22 -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 1qc8D0-0003lP-6G for emacs-devel@gnu.org; Fri, 01 Sep 2023 13:45:27 -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 1qc8Ci-0007AN-An; Fri, 01 Sep 2023 13:45:22 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 46ED31626C; Fri, 1 Sep 2023 19:44:56 +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=1693590295; bh=hvwoEujwIjk78P4JH/e7G5lVH6OLVBHX6eWAJ62omhQ=; b= QpebknNS00G/Hzbhi5am6Q5RztnZJ+Zv/xUiZ+NyHG+tcEN4qArVPeyd6ishpYtY vAvp1Audnprc1FXtow+AFH6patMYN1+B0md4yaCu75qvCFjhRVOvtX4PSDL5PnUj mQtVD/dFmYe7r0y4yvh7D5FVV2yjfkOsTPhsXA5JAM4= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id jXW6ZNOMLWaW; Fri, 1 Sep 2023 19:44:55 +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 D49FB162A5; Fri, 1 Sep 2023 19:44:55 +0200 (CEST) In-Reply-To: <83bkelc1p1.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: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 01 Sep 2023 14:27:20 -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:309829 Archived-At: Eli Zaretskii writes: >> From: Jonas Bernoulli >> Cc: rms@gnu.org >> Date: Fri, 01 Sep 2023 16:38:02 +0200 >> >> I think the next step is to ask Eli and others, how they would want to >> integrate the library / the functionality it provides. > > I'm probably missing something because if all we want is to allow > child processes to use the current Emacs session as their editor, we > just need to inject some environment variables into > process-environment when running those child processes, and start the > server. That's the core of what with-editor does. Additionally - It tries hard to find the correct emacsclient to use. - 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. - It provides some convenience functionality to use this from various shells running inside Emacs. > 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"? > 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. Maybe I miss something, but I concluded that emacs does *not* know its corresponding emacsclient. Once I know how to make use of that knowledge, I can simplify with-editor quite a bit, with will benefit the packages that already use it. And if that really is fail-safe, then Emacs doesn't have much to gain from integrating with-editor. >> As far as adding `server-window-alist' goes, that would certainly be >> a win. > > If we want to extend server-window in some ways, that could be a > separate change. It sounds like its utility is not necessarily > specific to with-editor or to its main feature of allowing > sub-processes use the parent Emacs as their editor. Agreed and that is something I was planning to suggest eventually, while I had no plan to suggest merging all of with-editor.el. > (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.