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 13:34:17 +0300 Message-ID: <83tumwml3q.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> <837djsobhw.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7885"; mail-complaints-to="usenet@ciao.gmane.io" Cc: bugs@gnu.support, emacs-devel@gnu.org To: monnier@iro.umontreal.ca, mail@daniel-mendler.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 21 12:36:08 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 1lk2Vj-0001hF-Mc for ged-emacs-devel@m.gmane-mx.org; Fri, 21 May 2021 12:36:07 +0200 Original-Received: from localhost ([::1]:59512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lk2Vi-0003YA-Ov for ged-emacs-devel@m.gmane-mx.org; Fri, 21 May 2021 06:36:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lk2Tz-000139-7n for emacs-devel@gnu.org; Fri, 21 May 2021 06:34:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50108) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lk2Ty-0007sN-UO; Fri, 21 May 2021 06:34:18 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2439 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 1lk2Ty-0003qx-4A; Fri, 21 May 2021 06:34:18 -0400 In-Reply-To: <837djsobhw.fsf@gnu.org> (message from Eli Zaretskii on Fri, 21 May 2021 09:18:51 +0300) 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:269547 Archived-At: > Date: Fri, 21 May 2021 09:18:51 +0300 > From: Eli Zaretskii > Cc: mail@daniel-mendler.de, bugs@gnu.support, emacs-devel@gnu.org > > > 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? Btw: in batch mode, read-from-minibuffer returns when it sees a newline, so you could still use the above if you'd process each incoming line, and then issued another read-from-minibuffer call only when the processing was done. So the situation we have doesn't look too bad to me.