4 ms·

> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well? Almost, but not quite. VSC doesn't give you javascript access to

> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well? Almost, but not quite. VSC doesn't give you javascript access to the internals of the application, it just provides a fairly broad set of extension APIs. You can see this in how the VSC equivalent of rainbow-delimiters-mode (parentheses and brackets recolored based on their nesting depth) had to be rewritten as part of the core application for performance reasons. This wasn't necessary for emacs.

convolvatron 5y ago
I'm doing a highly integrated language environment for a research language and faced this decision recently. elisp and javascript are both pretty iffy lisps, but at this point I think I'd prefer javascript. however VSCode presents an API around a specific notion of what a language is and how it interacts with the editor. emacs comes in at lower level and presents a model with just buffers and text. I remember elisp debugging as being a joy - not really finding that to be true. but I really don't want to be limited by what the VSC designers thought I should want to do with source files - actually I don't want to use source files at all.
- b3morales 5y ago
  > VSCode presents an API around a specific notion of what a language is and how it interacts with the editor I would say Emacs has this as well, in its syntax tables. They are its schema for "what a language can be" and especially "how the editor can interact with it".
  - convolvatron 5y ago
    yes - but those are completely optional
    - kqr 5y ago
      That is true of any editor: they will only seeem intelligent if you ask them about the languages they have support for.
- vintermann 5y ago
  By its nature software designers have to make some decisions on what should be easy, what should be possible and what you'd be better off using some other app for. If you're on something as radical as not using source code to describe a program (what are you using then? A DB of some sort?), I don't think either emacs or vscode can be your tool of choice. We know there's no free lunch, if an extensible development environment was flexible enough to make this sort of thing easier, something else had to be made harder.
slightwinder 5y ago
Emacs is not that much different there with it's C-core and lisp-land. It had even a similar case with the reimplementation of linenumber-mode in C for performance-reasons. The question is more what emacs can offer generally that vscode is lacking in ability, even just theoretically. Because in reality there are of course many features not implemented yet in vscode.

convolvatron 5y ago

I'm doing a highly integrated language environment for a research language and faced this decision recently. elisp and javascript are both pretty iffy lisps, but at this point I think I'd prefer javascript. however VSCode presents an API around a specific notion of what a language is and how it interacts with the editor. emacs comes in at lower level and presents a model with just buffers and text. I remember elisp debugging as being a joy - not really finding that to be true. but I really don't want to be limited by what the VSC designers thought I should want to do with source files - actually I don't want to use source files at all.

b3morales 5y ago
> VSCode presents an API around a specific notion of what a language is and how it interacts with the editor I would say Emacs has this as well, in its syntax tables. They are its schema for "what a language can be" and especially "how the editor can interact with it".
- convolvatron 5y ago
  yes - but those are completely optional
  - kqr 5y ago
    That is true of any editor: they will only seeem intelligent if you ask them about the languages they have support for.
vintermann 5y ago
By its nature software designers have to make some decisions on what should be easy, what should be possible and what you'd be better off using some other app for. If you're on something as radical as not using source code to describe a program (what are you using then? A DB of some sort?), I don't think either emacs or vscode can be your tool of choice. We know there's no free lunch, if an extensible development environment was flexible enough to make this sort of thing easier, something else had to be made harder.

slightwinder 5y ago

Emacs is not that much different there with it's C-core and lisp-land. It had even a similar case with the reimplementation of linenumber-mode in C for performance-reasons. The question is more what emacs can offer generally that vscode is lacking in ability, even just theoretically. Because in reality there are of course many features not implemented yet in vscode.