Re: Questions about throw-on-input

[Eli Zaretskii <eliz@gnu.org>]

> From: chad <yandros@gmail.com>
> Date: Fri, 15 May 2020 12:47:08 -0700
> Cc: Arthur Miller <arthur.miller@live.com>, Richard Stallman <rms@gnu.org>, 
> 	EMACS development team <emacs-devel@gnu.org>, p.stephani2@gmail.com, yyoncho@gmail.com, 
> 	alexanderm@web.de, Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
> 
> 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.