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: emacsclient in elisp Date: Fri, 21 May 2021 09:18:51 +0300 Message-ID: <837djsobhw.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25430"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mail@daniel-mendler.de, bugs@gnu.support, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 21 08:19:25 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 1ljyVJ-0006Pm-8p for ged-emacs-devel@m.gmane-mx.org; Fri, 21 May 2021 08:19:25 +0200 Original-Received: from localhost ([::1]:35876 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ljyVH-0005aY-MF for ged-emacs-devel@m.gmane-mx.org; Fri, 21 May 2021 02:19:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59902) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ljyUo-0004vj-Cu for emacs-devel@gnu.org; Fri, 21 May 2021 02:18:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33888) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ljyUm-0004BP-Op; Fri, 21 May 2021 02:18:52 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2512 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ljyUm-0005KL-5V; Fri, 21 May 2021 02:18:52 -0400 In-Reply-To: (message from Stefan Monnier on Thu, 20 May 2021 17:21:01 -0400) 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:269527 Archived-At: > From: Stefan Monnier > Cc: Daniel Mendler , bugs@gnu.support, > emacs-devel@gnu.org > Date: Thu, 20 May 2021 17:21:01 -0400 > > I'd expect in the server a loop like: > > (while t > (let ((cmd (read-from-minibuffer ""))) > (process-command cmd))) > > where `process-command` may launch async subprocesses or initiate > network connections or send commands to network connections, and the > above loop will not always immediately send replies but instead they may > be sent from the process filters and/or sentinels. > > With the current implementation of `read-from-minibuffer` this above > loop won't work because there is no time where process filters and > timers are processed, including when we're waiting in > `read-from-minibuffer`. But only if the above runs in batch mode, right? And as I wrote elsewhere, I don't understand why being able to read from stdin like it's a sub-process would be so much better than actually using a network process. We could introduce such a feature for the batch mode, but it would mean serious complications, and I just don't see the justification for that.