Re: Questions about throw-on-input

[chad <yandros@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

I was thinking about this recently, and, as a thought exercise, a
hypothetical emacs could adopt more of the web-browser model, based around
frames or windows rather than buffers. Things like completion windows would
be attached to a frame/window, but that's not conceptually hard, and
"better pop-up windows" is a nice-to-have anyway (people keep implementing
bespoke solutions for current emacs, and I believe a good internal facility
would be welcome).

I say "frame or window" because most editing use cases are built around a
single window with some transient extras (editing src/xdisp.c), with a few
common cases where multiple buffers are semantically linked (gnus, mu4e,
maybe slime/cider/gud) in a way that would be fine to share a single
thread, especially if the engine allowed for "workers" that could grab
(copy?) state, carry out some processing in the background, and then update
and release the state, similar to package-list-packages updating the
package list in the background while I look at various package-descriptions
in the foreground, or git updating while I read a log/diff.

By way of explanation (not endorsement), the email client I'm using right
now popped up a little message in the bottom-right corner that says "New
Message from Stefan Monnier  _Show_ _Ignore_", letting me know that the
state has been updated behind my view, and giving me the option to update
the view now or leave me alone while I finish my edits.

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?

Thanks,
~Chad

[-- Attachment #2: Type: text/html, Size: 2373 bytes --]