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 09:37:58 -0400 Message-ID: <873523pzk9.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> <87ilazq354.fsf@catern.com> <83cz17lt6l.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="32026"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:GolVpGK+WDXwNv58ANHlFbEoHXs= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 04 18:01:37 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 1qGiTA-00086g-VG for ged-emacs-devel@m.gmane-mx.org; Tue, 04 Jul 2023 18:01:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGiRm-0003do-Ai; Tue, 04 Jul 2023 12:00:10 -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 1qGgEP-0004l8-Q9 for emacs-devel@gnu.org; Tue, 04 Jul 2023 09:38:15 -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 1qGgEM-0003ZQ-SI for emacs-devel@gnu.org; Tue, 04 Jul 2023 09:38:13 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qGgEK-0006Rj-In for emacs-devel@gnu.org; Tue, 04 Jul 2023 15:38:08 +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 12:00:06 -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:307425 Archived-At: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Tue, 04 Jul 2023 08:20:39 -0400 >> >> Eli Zaretskii writes: >> >> >> >> 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. > > I never closely analyzed that, but just follow the control flow of > process_special_events and the functions it calls, and you will see > quite a few non-trivial things. > > My point is that most people aren't aware of how this works, so they > will be unable to decide whether their program can or cannot handle > this kind of processing while call-process is in progress. > >> > 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 > > Except when it isn't. E.g., with long lines, redisplay could take > several hundreds of milliseconds, and sometimes longer. > >> and I don't use any long-running Lisp programs. > > Maybe you don't, but others might. "Long" here doesn't have to be > minutes or hours, btw, it could be seconds. For example, sorting > incoming email could take that long if you've got a lot of it. > >> 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. > > We are talking about a general-purpose API used a lot in Emacs. We > are not talking about a feature only for your personal usage -- for > that you can do whatever you want locally. I mean as a general principle when writing Emacs Lisp. "Do expensive operations in separate processes" is advice I've heard and given many times, and certainly Emacs follows it in many places. >> 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? > > I'd prefer that you run with this locally for some time, and report > back any complications or issues. You have posted the patch, so if > someone else is interested, they can apply that locally and use it. OK, I'll install the patch I've posted at my site. It will include the process_special_events call, since that fixes the part that I've gotten user complaints about. I'll report back about how it goes in a couple weeks.