From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: emacsclient in elisp Date: Fri, 21 May 2021 11:33:23 -0400 Message-ID: References: <00ce8ae3-bb21-c58f-cd32-c196f146842b@daniel-mendler.de> <6fed43bb-d880-bcd5-6f6f-004b6182e539@daniel-mendler.de> <83pmxlo2z0.fsf@gnu.org> <922437d2-74ca-a7aa-cd1d-060f31d383e6@daniel-mendler.de> <83o8d5o0od.fsf@gnu.org> <186aa7ae-605d-3959-b923-ee5817c939f0@daniel-mendler.de> <83mtspnseg.fsf@gnu.org> <837djsobhw.fsf@gnu.org> <83tumwml3q.fsf@gnu.org> <83bl94m8fe.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="9230"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: mail@daniel-mendler.de, bugs@gnu.support, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 21 17:34:29 2021 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 1lk7AS-00029j-Th for ged-emacs-devel@m.gmane-mx.org; Fri, 21 May 2021 17:34:28 +0200 Original-Received: from localhost ([::1]:44838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lk7AR-0007X0-2B for ged-emacs-devel@m.gmane-mx.org; Fri, 21 May 2021 11:34:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36572) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lk79Y-0006q7-Cr for emacs-devel@gnu.org; Fri, 21 May 2021 11:33:32 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10481) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lk79U-0008AF-ES; Fri, 21 May 2021 11:33:31 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DAD3E807A1; Fri, 21 May 2021 11:33:26 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 33DB48067F; Fri, 21 May 2021 11:33:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1621611205; bh=PGuNz0et7Y2HhxXwb5wQ/tVhSZuxn1opU09lWJH3cho=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=djJTZQrr+H6ddkFVtGk5637aN+TaoRvIEgMs0QAx1yXGt9OupTs/cJpWpS2MdyGfQ v5mo+fm5VwHRYJVD1xZ9K7jE8bA4E4Ovkr47F2Yvsh50jIrdKkCpkLXSpG5pQEj162 sTG94IBaGBK9LVn1NsSZXQPKJ0bo1x7Tk6kmYkYrIpAPxpHoIzzUye3bbC1fJlZ67s gz9ZUtuY1pMcMHYvGMxsGBYDBxRedj8n9L1cDTKFAGvpDNtSYqFcBT4lTLiI37Mgen oFJ8JGNKZWU3n8s8qfQCax3S4lExgwOf/yGCOMPtPM19vTLIEEtogSa2c83Y6eySTr FgTGYh2KhRfeg== Original-Received: from alfajor (76-10-140-76.dsl.teksavvy.com [76.10.140.76]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EF3531205EA; Fri, 21 May 2021 11:33:24 -0400 (EDT) In-Reply-To: <83bl94m8fe.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 21 May 2021 18:08:05 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:269568 Archived-At: >> The next line may not come from another half-hour, or even "for ever" if >> the other side is waiting for our (asynchronous) answer before sending the >> next command. > So don't call read-from-minibuffer until you have processed the > previous job and sent out the results. That can prevent "streaming" like uses where you can receive several requests before you have the info needed to answer the first requests. Or other situations where you want to reply to requests out of order. >> There are cases where it's usable, but there are cases where it's >> a non-starter. > Why focus on the latter? Because it's the situation that Daniel is into, AFAIK (and because the other situations are already taken care of by the infrastructure we have, so we (Emacs developers working on the infrastructure for developers of third party packages) don't need to worry about those other cases). Stefan