Re: Buffers with buffers (transclusion)

[Eli Zaretskii]

> From: Vladimir Kazanov <vekazanov@gmail.com>
> Date: Thu, 17 Oct 2024 12:38:03 +0100
> Cc: jimjoe@gmx.net, emacs-devel@gnu.org
> 
> > With the displays we have nowadays, I'd say even 10 is not a problem,
> > and probably more.
> 
> Honestly speaking, I can't imagine a realistic way of manipulating 10
> windows in a uniform way.

One way to do that is using the windmove package, see
windmove-default-keybindings.  And I can easily envision other similar
ways.  In a nutshell, we can have commands to move between windows
bound to very simple-to-type keys.

> Or do you mean an additional flavour of windows? Like, a host window
> (group) owning subwindows, with all window decoration removed? And a
> set of commands working on this set of subwindows?

No, I mean basically the normal windows we have.

> > What are the use cases where you need more separate sources?
> >
> > > Doing this within a single window is just simpler.
> >
> > It isn't, IMO.  It raises several conceptual problems that are hard to
> > solve.  E.g., if you type text between the end of SRC1 and the
> > beginning of SRC2, to which source is this added?  Or how do you
> > handle font-lock?  Or what do you do if each source has its own major
> > mode?  And there are other similar issues, solving which will be
> > difficult even conceptually.
> 
> Yes, corner cases are complex.

These are not corner cases.  These are issues that pop up all over the
place as soon as you bring together text from separate sources.
Without a satisfactory solution for them, this feature will be only a
magnet for bug reports.

> > > Then, there's a performance question. One thing is to work on a 1-2k
> > > LOC, another is to jump between buffers potentially having tens of
> > > thousands of LOCs.
> >
> > Why do you envision a performance problem here?
> 
> I do not envision it, I feel it :-) Right now I am browsing
> xdisp.c/buffer.c and a bunch of other related buffers. Flymake, eglot,
> tree sitter all are just impossible to use as every time I switch to
> the next window all hell breaks loose. So I just switch things off
> completely.

tree-sitter is per buffer and handled locally, so I don't think it has
anything to do with switching buffers.  Eglot and Flymake are problems
that go right back to the conceptual difficulties I mentioned.  E.g.,
how do you use Eglot in a buffer that is not under a particular major
mode?  Same with Flymake.  I don't see how bringing text into a single
buffer could help here; I do see how it could break things.

> By the way, after reading the depths of xdisp.c's handling of display
> and buffer.c's exposure of the underlying chunks of memory I now
> wonder if it's easier to stream atomic changes between buffers? Say,
> given one region in buffer 1 and one region in buffer 2 enforce a sync
> of state (text and properties) between both regions.

Making the display engine show several buffers is actually very easy,
technically.  By contrast, the problems I mentioned above are much
harder, especially since it is not clear conceptually what the
solutions should be.