emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about throw-on-input


From: chad
Subject: Re: Questions about throw-on-input
Date: Fri, 15 May 2020 12:47:08 -0700


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]