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?
