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: call-process should not block process filters from running Date: Tue, 04 Jul 2023 14:10:57 +0300 Message-ID: <83y1jwkk3i.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21646"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: sbaugh@catern.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 04 13:11:16 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 1qGdwC-0005Up-Kv for ged-emacs-devel@m.gmane-mx.org; Tue, 04 Jul 2023 13:11:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGdvJ-00089m-Nv; Tue, 04 Jul 2023 07:10:21 -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 1qGdvI-00089c-DQ for emacs-devel@gnu.org; Tue, 04 Jul 2023 07:10:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGdvH-0006nh-S5; Tue, 04 Jul 2023 07:10:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tgGpjUjUZSFXFfng6RBP4EEv1/ooa0e2VNasTpAQdao=; b=AoyHy+6C8q2O NbmIaWePvfeYbg8zp9YjhMLaxnMlOV1YtZi09P3gJESe2G7BnBpW0je4xcT6ULKqU+68HQj5kLyll ALRrfExfLviZZX46RaaWJZ6v8kQZj2ZjqE1xW6ja2StmpAwcRYQHS2gjxRKRfA3bnbVOebNPjcMWE 7A5b+hovyUIHqcI7aCVt11d6Cwi4N4KjhkO2cnMXbI5YX3PV14FFO/J+tbHRCIjeu9FKAy9tITptQ qwCR+JC0GcL1HKC8VhJC71I2AyAPqdtj9Kc+QVjCdG5LpNVZ/9KefYEXLjMigkSbocD/Gl/8UxUw9 TJa8SBx/aR1Ff1ROHznyiA==; Original-Received: from [87.69.77.57] (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 1qGdvH-00014S-7j; Tue, 04 Jul 2023 07:10:19 -0400 In-Reply-To: <878rbwrb86.fsf@catern.com> (sbaugh@catern.com) 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:307407 Archived-At: > 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. > 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. > > 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.