Speaking of... By 1978 InterLISP had grown up quite a bit and its tree-based editor was quite powerful. It supported several tools like Masterscope and DWIM (Do What I Mean), the likes of which I would not see in text-based editors for almost two decades. It was quite habitable, even though a CLI tool and tree-based. I wrote all the code for my dissertation using that editor on a DEC-20. So much better than even EMACS at the time. The simplicity of S-expressions was critical to its success, IMHO. Extending the editor was simple, too. LISP, you know.

A long long time ago on a toy lisp called Interlisp/65 I used something that was like the s-exp equivalent of a line editor.

https://atariwiki.org/wiki/Wiki.jsp?page=Lisp

Source is here: https://atariwiki.org/wiki/Wiki.jsp?page=LispEditor

If you really wanted a vi-like experience for editing lisp, you could figure out how to make an editor like that full-screen and interactive.

I haven't added any yet, but all parsing is done with tree-sitter so languages can be added pretty quickly. One issue is that tree mode works on whole lines (I think the benefit of AST-style navigation vs moving a text cursor diminishes as the selections you want get smaller), so it's better suited to languages where the blocks are naturally separated by newlines as opposed to the ")))))" style.

Are you using the official tree-sitter grammars as-is? Or tweaking/writing your own to support your use case? From what I've seen not all of them are suited to structural editing, since the emphasis is on syntax highlighting.

Yeah using them as is and haven't had any issues so far. I think they are at a slightly lower level of abstraction than an AST, e.g. an async method in JS is a method_definition with an "async" node followed by a property_identifier, whereas an AST might wrap all this into an AsyncMethod node - but all the info you need is there.

Parsing on newlines is probably not a great fit for Lisp-syntax languages. Does the availability of LSPs make a difference? Asking as I don't know your tool.

Yeah, s-exprs don't break down by lines very well, but they are easy-ish to work with in a structured format, similar to HTML/XML editors since the delineation between elements is usually very clear. The only problem with lisps would be when macros are involved where there is more fluidity in the structure. But something like this:

  (defun double-all-the-things (things)
    (mapcar (lambda (x) (* 2 x)) things))

would be straightforward to navigate through with an s-expr aware editor.

It's more that the selection operates on whole lines in Tree mode, so it would parse fine with the tree-sitter grammar (for syntax highlighting etc) but selecting the inner contents of a block would take the block's closing ) with it. This would only matter if you wanted to move the contents somewhere though - editing and refactoring commands (including with the help of LSPs) will work, with the selection being the outermost node on the first selected line.

Paredit has entered the chat.

Interlisp, fructure