For decades programmers have had to write structured data (“programs”) in plain, unstructured text files. To make life easier, editors grasped at what few structural markers were generally available: editors like
ed let you insert, delete, or change entire lines; editors like Microsoft’s Notepad let you move around by word or by page; probably the most complete are editors like Vim and Kakoune that provide all sorts of fancy operations for working with sentences or string-literals or matching grouping symbols, but at this point we’re grasping for structures that might reasonably appear in a generic text file, or even a generic source-code file — anything more requires the editor to have syntax-specific understanding.
Vim and Kakoune actually do have that, in a very simple way. In many situations, rather than using a predefined movement or selection pattern, you can write a regular expression that describes a small part of the file’s structure, and navigate like that. Regexes are not easy, especially beyond the most basic uses, but it’s a lot simpler to write a regex occasionally than it would be to update Kakoune’s C++ code and recompile it for every file-type you wanted to edit. This combination of built-in support for generic structures, and ad-hoc support for specific structures through regexes, is very powerful and is a good part of the reason why Vi-lineage editors are still around nearly fifty years after Vi was first invented.
Powerful as it is, there’s still significant limitations. For example, the “jump to matching bracket” operation is frequently confused by brackets inside string literals. Trying to work on text inside comments frequently gets the comment markers mixed up with the content. Are
> grouping symbols or mathematical operators? Properly handling such things requires the editor to understand the specific file-format in question.
I definitely think the next killer feature of Vi-lineage editing will be structural knowledge, but I think it needs to be more like writing a regex or a Kakoune syntax highlighter than writing “real” code. I’d like to tell my editor that
comment = "//" not("\n")* and then anywhere I write a regex I can write
$comment to mean “text spans tagged as comments”. I’d like to try various structure patterns interactively, and when I find the ones I like, paste them directly into a file to make a grammar, like making a Kakoune plugin. I’d like to run an external program to generate a syntax tree in case the built-in structure pattern language isn’t flexible enough, in the same way that many Kakoune plugins generate
I’m pretty sure it would be possible to make an editor like that, and I’m pretty sure it would be great, but I think it would be too radical a change for Kakoune. And writing a brand new editor would take a long time to reach the maturity and polish and ecosystem Kakoune already has. So I’m not sure that editor will ever arise, but I’m keeping an eye out just in case.