From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: Re: A UI approach for making synchronous commands asynchronous Date: Fri, 28 Jul 2023 06:32:26 +0200 Message-ID: References: <83mszhnbez.fsf@gnu.org> <83sf99l7bc.fsf@gnu.org> <83fs59l0r0.fsf@gnu.org> <838rb1kv59.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T80f2tR1hzBadL8F" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9259"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 28 06:42:06 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 1qPFIj-0002D5-Ct for ged-emacs-devel@m.gmane-mx.org; Fri, 28 Jul 2023 06:42:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qPF9a-0003NY-9W; Fri, 28 Jul 2023 00:32:38 -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 1qPF9V-0003MJ-ER for emacs-devel@gnu.org; Fri, 28 Jul 2023 00:32:34 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qPF9T-00024W-7c; Fri, 28 Jul 2023 00:32:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cxWt4qFczqiyz+TLOpc3Imqc5iAxZ5ZpRUgup3YgyD4=; b=tVSw9tJwtA2Vcdp40GR8LW1Ors lTaBrVZWIfpoww/iqMdLGczT+BzGFzxmxSLX92TFX2n5pSAQaGb9MgyV2N7nxyYNDqKHtuAUcnYwi Mj7U20LwO/wvO+WvR9C0cC/1PoMAVhTxf2p8rmAsir1CXH+7DKAp2aRIRs1L/GR222wKynUpqVkLK GTkU1Lx+CGm2jk/cAxr6RioJTcg2SsSWmdAeYGDEJFZnagzg7PdlvSDNDD6HbnyxdB8zWdXp6SjLa rfevPTzwNpDCa308cciQEQQWVm1EGsruyel97ACRiX9M8TFvNYkmrotcRCrdw7z/TgpCz01pSGCv0 Dq658PYA==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1qPF9O-0007A4-Ad; Fri, 28 Jul 2023 06:32:26 +0200 Content-Disposition: inline In-Reply-To: <838rb1kv59.fsf@gnu.org> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:308179 Archived-At: --T80f2tR1hzBadL8F Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 27, 2023 at 10:32:34PM +0300, Eli Zaretskii wrote: > > From: Spencer Baugh > > Date: Thu, 27 Jul 2023 14:22:04 -0400 > >=20 > > Ideally the buffer would update incrementally with the new or removed > > names as they happen, and be fully updated once the rename is finished. > >=20 > > 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. > >=20 > > 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. >=20 > 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. I think Spencer is onto something here. The really "fun" part in all this multiprocessing part is the interaction with the user (as an independent entity). Spencer's idea is just one possibility. Another would be to just lock "part of a buffer" (whatever that means,see below): for example, in Org-Babel, where a snippet of the buffer is passed for evaluation to some external process and the results (think stdout) are inserted in a specific region of the buffer, you only have to keep a "lock" on this. Now, what happens if the user deletes a whole region containing that "part of the buffer"? How does Emacs signal to the user that this "part" is currently "moving"? Should that "part" be intangible? How does Emacs signal that it's "done"? I think Spencer's original mail was a proposal to think about such things and to try to discuss and develop "language elements" (not in the sense of "computer language", more of "user interaction language"), that's how I read his "user interface" term there. Spencer: am I right? thanks --=20 tom=C3=A1s --T80f2tR1hzBadL8F Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZMNE0wAKCRAFyCz1etHa RhvJAJ9TRSMhG0ZqAUQbBZW4vaRl6wHabwCfTRUn9dpZT1Xitk8hP4rX4vHKDPc= =k3n6 -----END PGP SIGNATURE----- --T80f2tR1hzBadL8F--