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: A UI approach for making synchronous commands asynchronous Date: Thu, 27 Jul 2023 08:58:12 +0300 Message-ID: <83mszhnbez.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4959"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 27 08:15:52 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 1qOuHv-00011D-Qy for ged-emacs-devel@m.gmane-mx.org; Thu, 27 Jul 2023 08:15:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qOu06-0007IO-Iu; Thu, 27 Jul 2023 01:57:26 -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 1qOu04-0007IG-AC for emacs-devel@gnu.org; Thu, 27 Jul 2023 01:57:24 -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 1qOu03-000609-Kt; Thu, 27 Jul 2023 01:57:23 -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=xUzOMCjd+Q+Vwhz9YzZTGvjvIBJXwkgmSTH/FZQUvWs=; b=FtGliQ+qgc56 KvCGnECXE0VNG7JH2dni8+mYHCJ57kfPxpKoFed07FZug522h9AiDeFQ0emsbKo1getZt3yUo4Vpd VpaQqQZEFArzpYpaXHVcvsoAGXvfHrR8uC1Jun22vtckT7Lgl18JAcMIc/G527Tm4q7Z5TQhL76DR IpLVaJPVtOW0HgRD9Q/gmxwChsDM6EjUPA/wN4FtuVwconePUuo12DUBbQZrBnDMQ2ObhmKF5Wmfg U3WH1eWC7AgMZjxiCSmWz3MN3JMFimC1xJRlxaCs9Lk31tmFB9hu1VGE0/xdYfdy7OG9PKV7XFhyb 2Tjr7kMytElt1kGb+1zuXQ==; 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 1qOu03-0000DH-3P; Thu, 27 Jul 2023 01:57:23 -0400 In-Reply-To: (message from Spencer Baugh on Wed, 26 Jul 2023 15:07:39 -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:308137 Archived-At: > From: Spencer Baugh > Date: Wed, 26 Jul 2023 15:07:39 -0400 > > > Basic well known facts: > - Sometimes Emacs blocks for a long time while performing a command > - This is annoying because I don't want to sit and wait > - Making it so I don't have to sit and wait requires two things: > Step 1. Changing the implementation of the command > (to be capable of running while Emacs handles user input) > Step 2. Changing the user interface of the command > (e.g. to display a buffer or message when the command is done) > > Step 1 is difficult on its own and is specific to individual commands. > I'm not going to talk about step 1 at all. (We've talked about it a lot > recently in the "Concurrency via isolated process/thread" thread) > > Instead, I have an idea for step 2! > > Even once step 1 is already done, step 2 is still a bunch of work: we > have to design a non-blocking UI for the command. You have lost me right here. In Emacs, commands don't have a UI: the job of displaying the buffer modified by a command is not a job commands must do. Instead, the display engine kicks in and does that. This feature is one of the basic design features of Emacs. So to talk about this, we must be on the same page regarding how this stuff works in Emacs. In addition, it is not clear what hides behind the "UI" notion that you have in mind. There are two aspects to UI: input and display. Which one are you talking about? Only the display or also about input (via the keyboard, mouse, window-system events etc.)? > The new feature is that if they get annoyed with how long a command is > taking, they can hit C-M-z to make the command "go into the background": > convert to some kind of non-blocking UI, like displaying a buffer with > progress or messaging when the task is done, as appropriate for the > individual command. > > We could also have a prefix (perhaps C-M-&) to run a command in the > "background" - that is, in a non-blocking way - from the beginning. How is this different from your Step 1, which is to change the command to run asynchronously (a.k.a. "in the background")? The main problem in what you describe is not delaying the redisplay (although it is also not trivial), it is the fact that while the command runs, something else, like user input, can change the buffer or some other aspect of the global state behind the command's back. Dealing with this is not a UI problem, it's a problem for the command. > In particular, I was thinking about this for file operations in dired. > Many dired file operations can take a long time, during which they block > Emacs. Actually changing their implementation to run during user input > handling (step 1) is a separate matter (and I have separate ideas about > how to do that), but I think the UI aspect (step 2) would be well served > by this "backgrounding" approach. Please describe in more details how this would work for some file operation in Dired. Suppose I mark some files and then run some command which searches them or renames them or deletes them -- how would this work under your hypothetical "backgrounding"?