Multiple files merged into one buffer


#1

I would like to share with you some thoughts about the way we deal with buffers and files in text editors in general.
Here’s an example to illustrate but it applies to virtually any scenarios.

While doing web-frontend code, I often have a triplet of files per “component”:

  • foo.html
  • foo.js
  • foo.css

These 3 files are tightly related and need to be kept in sync. For example if I change the name of a CSS class, it needs to be adjust it in the HTML tags using it and possibly in some JS selectors as well.

For this kind of refactoring, IDE are a huge help and LSP protocol and server can help on this side.(the “rename” function)

A more down to earth approach can be to use https://github.com/occivink/kakoune-find which performs a search and replace on multiple buffers. Great.

This leads me to this idea: what if the relations between a buffer and a file was not always one to one (buffer<>file), but a buffer could be some kind of virtual aggregate of multiple files?

In my example above, the text editor would display a long buffer with the the HTML at the beginning, a “visual separator”, then the JS, a “visual separator” and then the CSS part at the bottom? (the order is not important here).

So to select all the occurrences of the word “bar” in this virtual buffer, I would simply do a %sbar<ret> as usual. Then I’ll change these selections to “qux”, and a :w would save the changes to the 3 respective files.

The main idea of this post is: in text editors, why should we keep the “1 buffer per file paradigm” instead of having a fatty buffer with every files of a project inside it? (I’m voluntarily excluding memory consideration in the discussion for now, sticking to a philosophical approach)

Does this kind of workflow already exist in a tool somewhere?


#2

I’ve had this idea, but in terms of slightly another topic: why do we format code?

Why do we even care about formatting? I think it would be better to store code on disk in more optimized form, that is agnostic about formatting, and the editor will make file look how we want it to look. That’s what you’re talking about. The buffer will not be equal to file contents. This could also mean that a smart editor could pick several files and display contextual dependent parts alongside, or in more smart special form. And this could look the way any developer want it to look without complaining about using tabs over spaces, formatting curly braces without newlines, and other common rants.


#3

It’s kinda what Brackets does. You get contextual mini buffers where you can edit related files.

Opposite idea is narrowing from Emacs. It allows to hide parts of buffer and display only relevant parts.


#4

Looking at Brackets homepage I see what you mean by mini-buffers. VsCode also offer the same kind of “temporary portals” to peek into another buffer.

In this case, the boundaries between the 2 worlds remain quite strong, because it’s hard to apply text transformation in both place at the same time, especially with a mouse-less approach.

You’re right about Emacs narrowing system being the opposite.
If go along this analogy we could even consider that showing each buffers independently in a text editor is like having a “narrow view of the whole project source code”.