> I do wish something like emacs existed in slightly more modern form. I'd be thrilled if there was a modern text editor that allowed me to customize the app however I wanted by writing additional code in the language that the text editor is also written in (that is, repeating the relationship that emacs has with elisp).
Is there some reason you don't consider this to apply to vs code?
The process of writing Emacs-Lisp: open the scratch buffer, write a function and eval. The process of understanding what any part of the editor is doing: C-h f <function name>, read the documentation and link to the source is again right there. You can go to the source, set up a breakpoint, step through the code, understand it and even modify in place if you feel like it.
There is no other environment I know of, apart from smalltalk, that makes the process of extending and customizing the environment that frictional-less.
I have tried to understand the process of extending vs code, but it seems to require a lot of ceremony.
For instance, everything needs to belong in an extension, and you run the extension in different instance of vscode rather than the one in which you are editing the extension, which you have to reload/restart everytime you change the extension's definition.
The difference in experience is similar to the difference in experience in REPL-driven development in an interpreted language v/s developing in a compiled language with the whole edit/compile/run cycle.
VSCode is very good. I could write something about Lisp being homoiconic, also I don't know the VSCode equivalent of "advise", macros rewriting core functions of the editor, but I'll let someone else make that case, if they feel like it.
Is there some reason you don't consider this to apply to vs code?