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: Fri, 28 Jul 2023 09:21:25 +0300 Message-ID: <83zg3gk13u.fsf@gnu.org> References: <83mszhnbez.fsf@gnu.org> <83sf99l7bc.fsf@gnu.org> <83fs59l0r0.fsf@gnu.org> <838rb1kv59.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36291"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 28 08:22:11 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 1qPGrZ-0009F6-Tp for ged-emacs-devel@m.gmane-mx.org; Fri, 28 Jul 2023 08:22:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qPGq9-0008Qs-4W; Fri, 28 Jul 2023 02:20:41 -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 1qPGq5-0008E6-5x for emacs-devel@gnu.org; Fri, 28 Jul 2023 02:20:38 -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 1qPGq2-0003xH-HS; Fri, 28 Jul 2023 02:20:35 -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=NYWgzXbvR5EWPkMJ9o4yxVlaDCLNEczbG1eYq/j9Mho=; b=pG0Rw8NQJ09q gqnxy/icNJ2EhL9UDoxLI5cSvrgnTFfRPJLCWQRZzY4FUI/5KyblDaLJ6kDEKZCp4bQ+3Z1jZHkZi FhckYP8HDMQ6eBqYZJGxXD6R6/QWmE6c2tUsVfz7tCm5yu8evUaB6sMYBlBm0PbLxUBqgDteXw0o1 hy70+OL8CygitvwYlSIj3JNowai/EBAVEODcMucfOZAoPJXFpqoBFX4CNHNgJC5ReU+fEQzPPadYO 04hLafCwRXxrhPHvNu+/HHyLeZU4+GjzXrbdG2dBBMwNLlK9bMHRGDQenW7j9eMejNzrb+i93bM+d ekfGj522RALkgyUS5xGL1A==; 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 1qPGq1-0006IQ-2B; Fri, 28 Jul 2023 02:20:34 -0400 In-Reply-To: (tomas@tuxteam.de) 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:308184 Archived-At: > Date: Fri, 28 Jul 2023 06:32:26 +0200 > Cc: Spencer Baugh , emacs-devel@gnu.org > From: > > > 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). I'm not saying this doesn't deserve being discussed and considered. I'm saying that without some kind of plan for _implementing_ the features such a MO will need, discussing the UI aspects of this is not just premature, it could be simply a waste of everyone's time. Because if we conclude that making this happen in Emacs means redesigning and reimplementing most of Emacs, then those UI aspects are no longer relevant, since that "New Emacs", if someone will ever undertake the job of coding it, will look and feel differently anyway. > 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. Currently, the "lock" is implicit, because Emacs simply waits for the process to finish its work, and then inserts the output into the buffer, before it proceeds to processing any further input events. > 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"? These questions are currently irrelevant, because the problems cannot happen. Figuring how to allow Emacs do something while another thread runs a program which could affect buffers or other globally-visible data structures, is the main difficulty, and was/is discussed at length in the "concurrency" thread. > 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. I understand, but I don't believe we can develop such "language elements" without having some idea about the implementation aspects that would enable such behavior. Without such an idea, discussing the UI aspects has no basis on which to build it and on which to accept or reject proposals.