4 ms·
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, b
by 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 agoyes - but those are completely optional
- kqr 5y agoThat is true of any editor: they will only seeem intelligent if you ask them about the languages they have support for.
- vintermann 5y agoBy 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.