Re: Buffers with buffers (transclusion)

[Vladimir Kazanov]

> > Firstly, all of the editing always happens in one of the windows, not
> > across windows: search/replace, occur, grep. Having things in one
> > buffer makes these things as easy as editing a single small file.
>
> If the problem is to have some editing commands affect several
> buffers, we could implement such a feature without bringing all the
> text into a single buffer.  I'm guessing implementing such a feature
> will be easier and will have fewer conceptual problems than splicing
> text from different sources.


> 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. There's always some kind of a current
window, both the way things are in the Emacs C core, and also from a
UI perspective. Maybe that's just my setup though.

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?

> 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.

But Emacs does handle these problems, say, in overlays.

Polymode mangles major modes in a way that makes things usable with
multiple major modes imitated within a host buffer. In fact, solving
polymode's problems, or org-mode's src block problems, is what led me
to igniting this discussion.

Here's how this happens now in Polymode: an indirect buffer is
created, which gets a major mode, and then the mode's state is copied
over to the host buffer. I think it somehow handles keymaps as well
but I'd have to take a closer look.

Org-mode does something similar in src blocks: the code in question is
copied into a temporary buffer where the major mode specified by the
user is turned on, then text properties are copied over to the host
org buffer. Keymaps are not managed in any way.

> > 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. Sure, that's not directly related to the topic but
somewhat relevant for me anyway.

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.

-- 
Regards,

Vladimir Kazanov