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 20:31:31 +0300 Message-ID: <83fs59l0r0.fsf@gnu.org> References: <83mszhnbez.fsf@gnu.org> <83sf99l7bc.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23333"; 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 19:49:01 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 1qP56i-0005sK-Sl for ged-emacs-devel@m.gmane-mx.org; Thu, 27 Jul 2023 19:49:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qP4p1-0001SQ-V5; Thu, 27 Jul 2023 13:30:43 -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 1qP4p0-0001R0-GI for emacs-devel@gnu.org; Thu, 27 Jul 2023 13:30:42 -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 1qP4oz-0001LE-1B; Thu, 27 Jul 2023 13:30:41 -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=uNfu7+YJqq50FnPIkK8dVLuXuSpyT5gJ0DsbQhxpcW0=; b=ckCLzkCqMAn1 J5Ak2LI6oT1G+AfGMs2hj3OPODMVX5yuzJp53PsomZLobTGh3VWWa524UXVO8AbJtwT9lVCX6TJW+ 7N+W762Ax2FYcNE6GydXK47X6F22Fs+UDJrggqKPbJbxYsBUoiAHpc8WGxAAYqubZgO2TqF5LmGwY 6Ax72508s0ao3/FefDoBg4TVNofl2mfVtTqjj50YnnSzSuzrQEYVfQcnx4mI2f8PDyUkYuWE2J0tY cLOxsbqHoAFFo1+CL1S0pTv0kqbBB8w//M0ehXvovLZzHFQyNSHULxP87/cxHcU0dbCJUDKDY0uPF 0pCxULphnZAkPg+h5nAYiQ==; 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 1qP4ox-0005kD-Tv; Thu, 27 Jul 2023 13:30:40 -0400 In-Reply-To: (message from Spencer Baugh on Thu, 27 Jul 2023 11:32:33 -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:308164 Archived-At: > From: Spencer Baugh > Date: Thu, 27 Jul 2023 11:32:33 -0400 > > Eli Zaretskii writes: > > >> By "UI" I'm referring to the category of things which includes questions > >> like: > >> - should I call display-buffer or message here? > >> - what keybindings should I use for this set of commands? > >> - should I provide a prefix argument for so-and-so behavior, or > >> put it in a different command, or make it customizable? > > > > And you wanted _those_ to be asynchronous? What would that buy us?? > > No, I don't want those to be asynchronous. I'm explaining what "UI" > means, since you asked. There must be some kind of misunderstanding. In your OP, you said: 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! My interpretation of that is that you are suggesting to change the stuff you call "UI of the command" such that the user will not need to wait until the command finishes. Is that understanding correct? You then say that this "UI" consists of: By "UI" I'm referring to the category of things which includes questions like: - should I call display-buffer or message here? - what keybindings should I use for this set of commands? - should I provide a prefix argument for so-and-so behavior, or put it in a different command, or make it customizable? My interpretation of this was that you want to be able to use this stuff while one or more commands still run. Is that correct? If both of the above are correct, then you are, indeed, looking for making these aspects asynchronous. > > What happens if during the time the command runs "in the background", > > you go in the Dired display to one of the files that have been renamed > > and press RET? Or some command you invoke while the "backgrounded" > > one runs wants to access or visit one of the renamed files? > > Good question. I'd say, let's follow what the shell does. If you run > "mv ~/foo /mnt/sbaugh/foo &" and then run ls, you'll see some of the > files still in the source, some of the files in the destination. If you > try to access the former, you might get failures. Emacs does not work like a shell. For example, when a Dired command runs, it often changes the contents of the Dired buffer as it proceeds: e.g., renaming files modifies the Dired buffer to replace their old names with new ones. When other commands or you as the user want to access that buffer, what do you want to happen, and what do you want to see on display? A shell doesn't have these problems, it just writes stuff to the display and forgets about it. > The user already can go do other things that interact with those files, > while Emacs is moving them, which won't behave perfectly. So I don't > think we should take special care around them. I actually think this is a tip of a giant iceberg, even in this very simple example. Ignoring these aspects is not recommended, if we ever want something practical to come out of this. > I don't care about what the implementation is. I have thoughts about > how we could implement this, but I am not going to discuss it in this > thread, as I said in my initial email, since we already have a very long > thread about that. > > I just want to discuss what a good user experience would be, without > talking about implementation. This is necessarily somewhat speculative, > since we could describe designs which are hard to implement. That's > nevertheless what I want to do in this thread, since I think it's > useful. Talking about UX without also discussing the implementation of that in Emacs is not useful. We all know how it looks and feels to interact with a program where the UI, both input and output, are detached from the processing engine and can work in parallel with it. So I see no reason to discuss how this should look, because we already know that, and hardly disagree. What exactly do you expect to achieve by describing how C-z works in a Posix shell? are there any people around here who don't already know that? The problem is how to implement something like that in Emacs. IOW, the important part, and the only one worth discussing if we want practical results, is how to implement such features without rewriting all of Emacs.