From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Re: A UI approach for making synchronous commands asynchronous Date: Thu, 27 Jul 2023 14:22:04 -0400 Message-ID: References: <83mszhnbez.fsf@gnu.org> <83sf99l7bc.fsf@gnu.org> <83fs59l0r0.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="40108"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:Xp9xjpsFYOxr8fXsNE6RMV98+Ao= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 27 21:27:13 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 1qP6dl-000AHx-KL for ged-emacs-devel@m.gmane-mx.org; Thu, 27 Jul 2023 21:27:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qP6GZ-0003vR-NK; Thu, 27 Jul 2023 15:03:15 -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 1qP5cu-0007c8-Ax for emacs-devel@gnu.org; Thu, 27 Jul 2023 14:22:16 -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 1qP5cs-000799-Kr for emacs-devel@gnu.org; Thu, 27 Jul 2023 14:22:16 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qP5co-0008yW-Od for emacs-devel@gnu.org; Thu, 27 Jul 2023 20:22:10 +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: Thu, 27 Jul 2023 15:03:13 -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:308172 Archived-At: Eli Zaretskii writes: >> > 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. Ideally the buffer would update incrementally with the new or removed names as they happen, and be fully updated once the rename is finished. That can be difficult to implement, though. And also, for some kinds of operations, it's not clear what the buffer should look like while the command is half-done. So here's another idea that would help with that: maybe we could have a kind of buffer-specific blocking. A "blocking" buffer would refuse all input and commands while it's "blocking", and it wouldn't update, but the user can switch to other buffers and edit them without a problem. So, buffer-specific commands wouldn't work, but commands like C-x b and C-x o would work. It might be kind of like how term-mode works today. So in that world, the user would execute a dired rename operation, and then execute C-M-z to background it, and that would cause that dired buffer to stop responding while the rename is proceeding, while other buffers continue to work. One question is what happens to the user's input when the buffer "blocks". Today when Emacs as a whole is blocking, key input gets queued up and executed when Emacs resumes. Should the same happen for blocking buffers? Or maybe any key input should just immediately result in errors being printed? The latter seems preferable, and it wouldn't be a compatibility break because the user would have to run C-M-z to trigger such behavior.