From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Questions about throw-on-input Date: Sat, 16 May 2020 14:29:50 +0300 Message-ID: <83r1vkce35.fsf@gnu.org> References: <8920fe6a-8fe4-addd-c29e-2213850bf974@web.de> <83k11f7v4q.fsf@gnu.org> <4506133a-5e63-4ae7-9b5d-830359e8b673@default> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="114235"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, emacs-devel@gnu.org, p.stephani2@gmail.com, yyoncho@gmail.com, arthur.miller@live.com, alexanderm@web.de, drew.adams@oracle.com, monnier@iro.umontreal.ca To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 16 13:30:45 2020 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 1jZv1h-000TdW-J8 for ged-emacs-devel@m.gmane-mx.org; Sat, 16 May 2020 13:30:45 +0200 Original-Received: from localhost ([::1]:35282 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZv1g-0007ie-Hc for ged-emacs-devel@m.gmane-mx.org; Sat, 16 May 2020 07:30:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42190) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZv1C-0007Jc-9P for emacs-devel@gnu.org; Sat, 16 May 2020 07:30:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40335) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZv1A-0007hZ-C1; Sat, 16 May 2020 07:30:12 -0400 Original-Received: from [176.228.60.248] (port=3269 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZv11-0002Lj-9I; Sat, 16 May 2020 07:30:03 -0400 In-Reply-To: (message from chad on Fri, 15 May 2020 12:47:08 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:250476 Archived-At: > From: chad > Date: Fri, 15 May 2020 12:47:08 -0700 > Cc: Arthur Miller , Richard Stallman , > EMACS development team , p.stephani2@gmail.com, yyoncho@gmail.com, > alexanderm@web.de, Eli Zaretskii , Drew Adams > > The idea here is to create potential boundaries between the giant shared-mutable soup ala Oberon, Squeak, > and (from what I understand) LispM, while still allowing useful shared state. In this hypothetical world, what > are the cases where making most mutable data frame/window-local and building a minimal shared arena for > explict lock/mod/copy state would break down? I can imagine that a list of current buffers, for example, would > need to cross that boundary. Would project-wide search, edit, and refactoring tools be too constrained if a > project had to live within a single frame/window? Does the tab-bar/tab-line interface help us figure out how to > present the boundaries to the user in a helpful way? I admit that I don't really understand what you are suggesting. The Web browser model doesn't really help since, as Stefan pointed out, almost nothing is shared between different pages being shown in different windows/tabs in a browser, in stark contrast to what happens in Emacs. Making threads local to windows immediately brings up a question about the same buffer being shown in more than one window, something I tend to do a lot when studying code or writing something in one place of a buffer by looking at what another place does. Another piece of the global shared state is all the lists we maintain that make Emacs help us, like suggest defaults by using history. Most of that will be severely punished by limiting those lists to a single window, especially if you consider that windows are ephemeral and get deleted a lot. Even redisplay is a problem: while on GUI frames it works on each window independently from others, that is not so on TTY frames, where optimal redrawing of the screen dictates us to redraw on the frame level. So I think your proposal will need to be much more detailed before it can be seriously considered. Which is actually one of the more profound lessons I learned from hacking Emacs: it is never enough to have the general idea of how things work, no matter how accurate that general idea is. The devil is in the details, and those details will present tough problems, some of which will invalidate the proposed solutions. You must consider at least the main of those details up front, or your solution will be revealed as unworkable after a lot of efforts were already invested. My suggestion is to take a small number of common commands and see how much of the global state is involved in their execution, both on the Lisp level and on the C level. Then you might have a better idea how to subdivide the global state, and maybe even whether it is feasible to subdivide it into any meaningful parts.