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 22:32:34 +0300 Message-ID: <838rb1kv59.fsf@gnu.org> References: <83mszhnbez.fsf@gnu.org> <83sf99l7bc.fsf@gnu.org> <83fs59l0r0.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4483"; 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 21:44:19 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 1qP6uJ-0000wo-OF for ged-emacs-devel@m.gmane-mx.org; Thu, 27 Jul 2023 21:44:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qP6iA-0002ZW-2X; Thu, 27 Jul 2023 15:31:46 -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 1qP6i9-0002ZJ-9O for emacs-devel@gnu.org; Thu, 27 Jul 2023 15:31:45 -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 1qP6i8-00010r-4s; Thu, 27 Jul 2023 15:31:44 -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=Knvcm3v6ILWJm/+Pogr/PDwNzY8c+zpTmuYa+X4agAg=; b=qxpnX/YjmILF /dAUdaXEgsyp4iv3fq4yd3y31YpOsy2aj5F0ljXHIUt9enS8LPdm6yBu7Axs3HQuY8fVYadaRtYWv P0dfIjcO7T6dDaeuTES/ulQcKB91VBx40aL62/3SJabF9XtFOHKOG+dRQNTg1+okFKWsr6fU6CkhA 5YRI2EheWIpdVvTEygP6CSo7/sLDaudeAB6F3z6W9uk7uFhIoRPZec1JHtTFBWD/Opq5wZ584owN1 d3bYJNt0XGqbcV4uWgP9//ER8dMUpsE6+cBi6GYPE3eGwznAWXRdesLEnKVZPrYEvL5HGm8kJ31HM U59LkAIc5aganrccyQgPMQ==; 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 1qP6i6-0003QB-Q3; Thu, 27 Jul 2023 15:31:43 -0400 In-Reply-To: (message from Spencer Baugh on Thu, 27 Jul 2023 14:22:04 -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:308173 Archived-At: > From: Spencer Baugh > Date: Thu, 27 Jul 2023 14:22:04 -0400 > > 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. Here you already describe the same "blocking" or "locking" that was discussed at length in the other thread about concurrency. Which I think means that you are basically thinking about the same ideas with the same issues and possible solutions. It is not a different set of ideas. > 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. Queuing input means blocking UI, so if we lock various parts of Emacs while a command runs, we will have achieved nothing.