From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.devel Subject: Re: call-process should not block process filters from running Date: Tue, 04 Jul 2023 08:20:39 -0400 Message-ID: <87ilazq354.fsf@catern.com> References: <83cz1fvjef.fsf@gnu.org> <83h6qnpieb.fsf@gnu.org> <837criq321.fsf@gnu.org> <87r0pprhfd.fsf@catern.com> <87o7kts4ba.fsf@yahoo.com> <87lefwrif5.fsf@catern.com> <834jmkn7zt.fsf@gnu.org> <878rbwrb86.fsf@catern.com> <83y1jwkk3i.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="31397"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:htjbLtvVnIfCpCEmPA0c4jYSUdY= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 04 14:33:41 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 1qGfDw-0007sU-1e for ged-emacs-devel@m.gmane-mx.org; Tue, 04 Jul 2023 14:33:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGfDg-0001pv-RN; Tue, 04 Jul 2023 08:33:24 -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 1qGf1e-0001F8-Tj for emacs-devel@gnu.org; Tue, 04 Jul 2023 08:20:58 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGf1Z-0007Tp-8n for emacs-devel@gnu.org; Tue, 04 Jul 2023 08:20:58 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qGf1W-00092r-Hj for emacs-devel@gnu.org; Tue, 04 Jul 2023 14:20:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 04 Jul 2023 08:33:09 -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:307412 Archived-At: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Mon, 03 Jul 2023 16:28:25 -0400 >> >> Eli Zaretskii writes: >> > I'm not sure the new code should call swallow_events, even if >> > protected by some variable. We will be giving people a too-long rope >> > to hang themselves. It is unreasonable to assume Lisp programmers >> > will be able to decide when to allow this and when not to, given the >> > complexities. >> >> What is complex about this? > > Whatever caused you to be surprised that just calling > wait_reading_process_output doesn't process selection requests. How > many Lisp programmers understand what is going on in Emacs when such a > request is processed, and what that means for their Lisp programs? > >> What problems can it cause that aren't already covered by "arbitrary >> Lisp will run during call-process"? > > Processing selection requests does not really qualify as "running > arbitrary Lisp". It is much more subtle, and I'm quite sure the > mental model of that which most Emacs users have is very simplistic. I take your point, but can you be a little more concrete? I genuinely don't know what potential issues you're referring to that can be caused by processing selection requests in a new place. I'm asking just to improve my knowledge of Emacs. >> If swallow_events is too general, I can just call only >> process_special_events if necessary. > > They are both potentially dangerous. > >> AFAIK this is a pretty small change, all it changes is letting Emacs >> handle X selection requests while in call-process. (i.e. letting other >> X clients paste when Emacs owns the selection) > > Famous last words ;-) > > There are no "small changes" in Emacs on this level. > >> > Why do we need to jump through all the hoops right at the beginning? >> > Why not make a small step forward and see if this experiment is more >> > useful than it is dangerous? Then we could decide whether to make the >> > next step, and how. No one said that pasting into Emacs while a >> > subprocess runs is the most important capability to enable. I'd first >> > make sure the user can type at the keyboard without adverse effects. >> >> It's not pasting into Emacs, it's pasting into other X clients. I >> indeed don't care about pasting into Emacs while a subprocess runs. But >> I like to be able to use other X clients, including by pasting, while a >> subprocess runs. > > Still not important enough, IMO, for us to have to solve this right > away, since you will have the same issue when Emacs is busy with > something else, like redrawing the display or even executing some > long-running Lisp program. Redrawing the display is much quicker, and I don't use any long-running Lisp programs. In fact, I move long-running operations out into asynchronous subprocesses so they can run concurrently with Emacs. It's only call-process usage that makes Emacs noticeably busy for me. (As a tangent, it's kind of sad that this call-process API has ever caused Emacs to block/stop running Lisp - subprocesses are inherently concurrent! They are what we use if we want Emacs to *not* block. I understand that that's complex, but it's just kind of ironic.) >> > Let's not over-engineer this without a sufficient justification. >> >> I've received lots of user complaints about the inability to paste in >> other X clients while Emacs is sitting in call-process. Fixing that is >> one of my key motivations for this change. > > Nothing's wrong with fixing this step by step, from where I stand. OK. So what's the next step in this step-by-step from your perspective? Should we install the option on trunk, let people use it, and gradually make what it does broader and more fine-grained over time?