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 < and > grouping symbols or mathematical operators? Properly handling such things requires the editor to understand the specific file-format in question.
At this point a lot of people start talking about giving the editor deep knowledge of syntax, like an AST editor, or a JetBrains IDE, but it turns out this is a lot of work. For all the experience and institutional knowledge JetBrains has about editing structured programs, they currently sell eleven specialised IDEs — there must be thousands or even millions of file-formats and syntaxes in the world, it’ll never be possible to write a JetBrains-tier IDE for every single one. A tool like Tree Sitter is a lot simpler, but developing a Tree Sitter grammer still requires writing a grammar in JavaScript, compiling it to C, then compiling the C into your program — orders of magnitude more effort than writing a regex.
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 range-specs highlighters.
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.