I wish source code editors were much more AST-oriented rather than row-column-oriented. Sure, it’s more difficult when your grammar is more complex than s-expressions, but most editors these days maintain an AST of the source in real time anyway.
Features such as selection that grows "inside out" (or bottom-up) rather than line by line, moving a selection around to the next/previous valid position, moving various delimiters around to next/previous valid position, enclosing whatever’s under the cursor in a new block/pair of parens, and so on.
Unless we’re talking about FORTRAN or COBOL circa 1960, source code is a tree natively and text only incidentally.
Have a look at Neovim with its Tree-Sitter parser, it enables such 'growing selections' natively.
It's also relatively easy to write plugins based on the parsed AST. I wrote treesitter-unit[1] making it easy to select/modify the subtree of the selection.
I have been learning Racket on and off for the last few years as part of an interest in DSLs. (The documentation is well written, but I confess a certain kind of impatience with it because it is hard for me to get task-specific information when I'm trying to solve a particular problem.)
I recently had to remove parinfer because its inferences in multi-line syntax-parse statements were not great: I had to join a bunch of lines together to put in the parentheses I needed and lost placement. Parinfer's unwillingness to let me balance parentheses manually is a frustration. Am I misusing it?
Features such as selection that grows "inside out" (or bottom-up) rather than line by line, moving a selection around to the next/previous valid position, moving various delimiters around to next/previous valid position, enclosing whatever’s under the cursor in a new block/pair of parens, and so on.
Unless we’re talking about FORTRAN or COBOL circa 1960, source code is a tree natively and text only incidentally.