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: Sat, 22 May 2021 15:26:43 +0300 Message-ID: <835yzbkl8c.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> <83cztkm8hu.fsf@gnu.org> <831ra0lyrb.fsf@gnu.org> <83y2c7l2l9.fsf@gnu.org> <7fba8daf-a3f0-88a0-dcd4-4b9bae033dbb@daniel-mendler.de> <83cztjkr4m.fsf@gnu.org> <83bl93kqnk.fsf@gnu.org> <53abac6a-88d6-e691-e8e5-eea602c0f295@daniel-mendler.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38175"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 22 14:27:49 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 1lkQjN-0009m1-33 for ged-emacs-devel@m.gmane-mx.org; Sat, 22 May 2021 14:27:49 +0200 Original-Received: from localhost ([::1]:52052 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkQjM-0001ki-4r for ged-emacs-devel@m.gmane-mx.org; Sat, 22 May 2021 08:27:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47660) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkQiM-0000Jt-BV for emacs-devel@gnu.org; Sat, 22 May 2021 08:26:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58530) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkQiK-0006Hu-Te; Sat, 22 May 2021 08:26:45 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2468 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 1lkQiK-0002pR-Db; Sat, 22 May 2021 08:26:44 -0400 In-Reply-To: <53abac6a-88d6-e691-e8e5-eea602c0f295@daniel-mendler.de> (message from Daniel Mendler on Sat, 22 May 2021 13:49:20 +0200) 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:269608 Archived-At: > Cc: emacs-devel@gnu.org > From: Daniel Mendler > Date: Sat, 22 May 2021 13:49:20 +0200 > > >>> For my use case this would not be harsh. A running Emacs will explicitly > >>> opt-in to use the special make-stdio-process to read from stdin. This > >>> special process will only be used by external worker Emacsen controlled > >>> from the main Emacs. In that scenario the data flowing over stdin-stdout > >>> is tightly controlled (IPC protocol). There hopefully won't be spurious > >>> read-from-minibuffer calls. > >> > >> The last assumption is questionable > > > > I mean in general, not for the single use case you described. > > I agree that it is questionable in general. However given that the use > of `make-stdio-process` is opt-in, the change in behavior would not be > severe. No one said that by opting-in to this behavior a Lisp program gives up the ability to ask user questions via the minibuffer. I can easily imagine programs that would like to do both. > One could also keep the current behavior of `read-from-minibuffer` > as is, even if `make-stdio-process` is used. ??? How do you know which stdin input should go one way and which should go the other way? > The question is if that would shadow some bugs, since you probably > don't want to use both of them at the same time. What do you mean by "at the same time"? If I have a stdin-process active, we watch it via pselect and read from it using the machinery in wait_reading_process_output and accept-process-output. During all the time such a process is active, I see no way to also read from the same descriptor bypassing the above mechanisms, in a way that won't cause trouble on the Lisp level, due toe the basic inability to decide which input should go what way.