8 ms·

> What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. If you substitute Javascript for Lisp, doe

> What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well? So now there's a product that leverages the architectural advantages of Emacs, with modern defaults across the board.

hollerith 5y ago
Unless I was very unlucky in my decisions about what and how to learn about vscode or my ability to learn has dropped more than 10-fold between the time I learned to modify Emacs and the time I tried to learned to modify vscode (which is unlikely but not impossible: it was an interval of 28 years) emacs is much easier to learn to modify than vscode is unless one is already a web dev. Of course, if one does learn how to modify vscode, one has a skill (namely, web dev) in much higher demand on the labor market than knowledge of Emacs Lisp.
kqr 5y ago
I haven't personally used VS Code much, but from what I understand, it still runs in two castes that don't, generally, mix: there's its core code, and then there's plugins, and the latter exists on a separate plane from the former. You can't write a plugin that redefines some core behaviour. The functions internal to the core are not all automatically accessible for any plugin. Plugins don't become fully integrated with the core code to the point where the source file location is your only hint as to whether behaviour comes from a plugin or core functionality. (A non-Emacs user might very well go "Emacs plugins can do what now?" at the description of a plugin re-defining a core function. That's a fully understandable reaction. That level of hackability is not for everyone. But as far as I can tell, it's unique to Emacs and very small set of other software.) But I could be misunderstanding this. Maybe VS Code actually does have Emacs-level hackability, in which case I'd probably want to try it out more than I have!
- vintermann 5y ago
  No, I do not go "Emacs plugins can do what now". I rather go, "and that is supposed to be a good idea?". If you want to use Emacs as an OS, doesn't protected mode seem like a desirable feature?
  - kqr 5y ago
    From personal experience, I've benefited way more from that than I've been hurt by it. Whether that's true for all people I don't know. Of course, you're not supposed to do it other than very carefully and it has caused me problems when some plugin has made a mistake in a way that worked for the original author but not for me, but because of the openness of the system, it's fairly easy to "overwrite it back" automatically when the plugin is loaded – and submit a patch back upstream. So maybe this sort of system works only when a large portion of the users are hackers, and making Emacs more popular is not a good idea!
- m45t3r 5y ago
  Yeah, exactly. For example, evil-mode is still miles better than VSCode Vim plugins just because it works everywhere. Any buffer that my Emacs opens I can still use my Vim shortcuts (so it doesn't change that I open a text, a binary, file manager, a fuzzy search or PDF). Compared to this, on VSCode I basically need to explicitly say "make vim commands do this in this context" for everything I need.
  - deviaan 5y ago
    My current client wants all of us to standardize on VS Code at some point, and this is by far the most annoying thing for me. I hate that if I leave the editor, it goes back to a mouse-driven design. I'm glad to hear you can change the behavior, so I guess I'll just have to do that at some point to make it work for my needs.
  - 1ark 5y ago
    This is the main reason I changed and do most of my work in Emacs, keyboard only. Using it in terminal is a bit of a bonus. Onivim2 seems promising in bridging the gap, but we'll see.
NoGravitas 5y ago
> 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.
Mikeb85 5y ago
> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well? For the most part, except for the fact VSCode is owned by MS and has just enough proprietary code to break a lot of functionality if you try to use it without the proprietary bits.
- warkdarrior 5y ago
  > For the most part, except for the fact VSCode is owned by MS and has just enough proprietary code to break a lot of functionality if you try to use it without the proprietary bits. That's a personal policy choice, not a technical concern.
  - Mikeb85 5y ago
    Let's face it, the fact it's free software is the reason it's used at all, the reason it's been hacked on by so many people, etc... It's always relevant to discuss it's free nature, especially when discussing it's popularity.
eadmund 5y ago
Ah, but Javascript is a profoundly terrible language to do anything in, while Lisp is a joy to write in. Being a Lisp machine is core to the value of Emacs. Emacs-without-Lisp is just another editor.
- spiderice 5y ago
  > Javascript is a profoundly terrible language to do anything in Makes it really hard to take anything you say seriously when you reveal just how ok with extreme hyperbole you are
- Zababa 5y ago
  What do you find profoundly terrible about JavaScript?
- Steltek 5y ago
  eLisp? Where lexical scoping is this brand new feature that generates compiler warnings? Where the UI thread is the same as your eLisp thread? Where multiprocessing is a super clunky fork-exec with a weird side buffer? Where a simple regular expression works differently between what the user invokes and how you'd write it in a function? Yeah, it's a super joy to write.
  - oblio 5y ago
    It is a joy. When writing code in the ivory tower :-)
  - r-zip 5y ago
    As someone who uses Emacs and likes writing lisp, 100% agree. elisp is without a doubt the worst lisp still in common use.
- edgyquant 5y ago
  I disagree, I like JavaScript
- foldr 5y ago
  Elisp arguably has worse warts than Javascript. For example, non of Javascript's legacy 'var' scoping nonsense compares to elisp's archaic model of using dynamic scope for everything by default. On top of that, modern Javascript implementations are of extremely high quality, whereas Elisp is stuck with an interpreter of mediocre performance.
krylon 5y ago
I have not played with VS Code a lot, but I get the impression that, yes, they aim for something similar. I'm not qualified to judge, though, how successful they are so far. FWIW, when I hear people talk about VS Code, they appear to like it very much. But AFAICT, it has some way to go to catch up with all the functionality emacs has accreted over 30+ years. Also, there is an effort replace the old lisp engine inside emacs with GNU Guile, which is a JIT compiler that supports Scheme, ELisp, and Javascript. I have not tried it so far, but it might become possible to customize and extend emacs with Javascript in the not-so-distant future.
- oblio 5y ago
  Isn't the Guile effort practically dead? I remember hearing about it 10 years ago. It was actually started in 2000 and doesn't seem to have progressed since 2014: https://emacsninja.com/posts/state-of-emacs-lisp-on-guile.html https://emacsninja.com/posts/state-of-emacs-lisp-on-guile.ht... Plus, even if it's finished, will it get any traction in the ecosystem? Will the ecosystem start moving to it to take advantage of its unique benefits? Who knows? Bonus: Have you heard of GNU Hurd? :-)
  - krylon 5y ago
    I honestly don't know about the state or progress of Guile Emacs. I know it exists, but I haven't followed it beyond that. Assuming it gets "finished" (is any software ever finished?), it should be no-brainer as long as it provides backward compatibility with old elisp code. And open up the emacs ecosystem to Scheme and Javascript, which could make it much more attractive to newcomers. But, as they say, I'll believe it when I see it. The trouble with Hurd, IMHO, is that I've run out of jokes. We used to joke that it would run Duke Nukem Forever out of the box, but that one actually got finished. Then it was Perl 6, but that has arrived, too. Star Citizen maybe?
  - r-zip 5y ago
    Yes, Guile Emacs got abandoned, at least the last time I checked.
- stjohnswarts 5y ago
Zababa 5y ago
Not exactly, VSCode is more of an editor that can accept very advanced plugins. The "virtual JavaScript machine with a standard library for writing graphical (text) applications." is a web browser.

hollerith 5y ago

Unless I was very unlucky in my decisions about what and how to learn about vscode or my ability to learn has dropped more than 10-fold between the time I learned to modify Emacs and the time I tried to learned to modify vscode (which is unlikely but not impossible: it was an interval of 28 years) emacs is much easier to learn to modify than vscode is unless one is already a web dev. Of course, if one does learn how to modify vscode, one has a skill (namely, web dev) in much higher demand on the labor market than knowledge of Emacs Lisp.

kqr 5y ago

I haven't personally used VS Code much, but from what I understand, it still runs in two castes that don't, generally, mix: there's its core code, and then there's plugins, and the latter exists on a separate plane from the former. You can't write a plugin that redefines some core behaviour. The functions internal to the core are not all automatically accessible for any plugin. Plugins don't become fully integrated with the core code to the point where the source file location is your only hint as to whether behaviour comes from a plugin or core functionality. (A non-Emacs user might very well go "Emacs plugins can do what now?" at the description of a plugin re-defining a core function. That's a fully understandable reaction. That level of hackability is not for everyone. But as far as I can tell, it's unique to Emacs and very small set of other software.) But I could be misunderstanding this. Maybe VS Code actually does have Emacs-level hackability, in which case I'd probably want to try it out more than I have!

vintermann 5y ago
No, I do not go "Emacs plugins can do what now". I rather go, "and that is supposed to be a good idea?". If you want to use Emacs as an OS, doesn't protected mode seem like a desirable feature?
- kqr 5y ago
  From personal experience, I've benefited way more from that than I've been hurt by it. Whether that's true for all people I don't know. Of course, you're not supposed to do it other than very carefully and it has caused me problems when some plugin has made a mistake in a way that worked for the original author but not for me, but because of the openness of the system, it's fairly easy to "overwrite it back" automatically when the plugin is loaded – and submit a patch back upstream. So maybe this sort of system works only when a large portion of the users are hackers, and making Emacs more popular is not a good idea!
m45t3r 5y ago
Yeah, exactly. For example, evil-mode is still miles better than VSCode Vim plugins just because it works everywhere. Any buffer that my Emacs opens I can still use my Vim shortcuts (so it doesn't change that I open a text, a binary, file manager, a fuzzy search or PDF). Compared to this, on VSCode I basically need to explicitly say "make vim commands do this in this context" for everything I need.
- deviaan 5y ago
  My current client wants all of us to standardize on VS Code at some point, and this is by far the most annoying thing for me. I hate that if I leave the editor, it goes back to a mouse-driven design. I'm glad to hear you can change the behavior, so I guess I'll just have to do that at some point to make it work for my needs.
- 1ark 5y ago
  This is the main reason I changed and do most of my work in Emacs, keyboard only. Using it in terminal is a bit of a bonus. Onivim2 seems promising in bridging the gap, but we'll see.

NoGravitas 5y ago

> 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.

Mikeb85 5y ago

> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well? For the most part, except for the fact VSCode is owned by MS and has just enough proprietary code to break a lot of functionality if you try to use it without the proprietary bits.

warkdarrior 5y ago
> For the most part, except for the fact VSCode is owned by MS and has just enough proprietary code to break a lot of functionality if you try to use it without the proprietary bits. That's a personal policy choice, not a technical concern.
- Mikeb85 5y ago
  Let's face it, the fact it's free software is the reason it's used at all, the reason it's been hacked on by so many people, etc... It's always relevant to discuss it's free nature, especially when discussing it's popularity.

eadmund 5y ago

Ah, but Javascript is a profoundly terrible language to do anything in, while Lisp is a joy to write in. Being a Lisp machine is core to the value of Emacs. Emacs-without-Lisp is just another editor.

spiderice 5y ago
> Javascript is a profoundly terrible language to do anything in Makes it really hard to take anything you say seriously when you reveal just how ok with extreme hyperbole you are
Zababa 5y ago
What do you find profoundly terrible about JavaScript?
Steltek 5y ago
eLisp? Where lexical scoping is this brand new feature that generates compiler warnings? Where the UI thread is the same as your eLisp thread? Where multiprocessing is a super clunky fork-exec with a weird side buffer? Where a simple regular expression works differently between what the user invokes and how you'd write it in a function? Yeah, it's a super joy to write.
- oblio 5y ago
  It is a joy. When writing code in the ivory tower :-)
- r-zip 5y ago
  As someone who uses Emacs and likes writing lisp, 100% agree. elisp is without a doubt the worst lisp still in common use.
edgyquant 5y ago
I disagree, I like JavaScript
foldr 5y ago
Elisp arguably has worse warts than Javascript. For example, non of Javascript's legacy 'var' scoping nonsense compares to elisp's archaic model of using dynamic scope for everything by default. On top of that, modern Javascript implementations are of extremely high quality, whereas Elisp is stuck with an interpreter of mediocre performance.

krylon 5y ago

I have not played with VS Code a lot, but I get the impression that, yes, they aim for something similar. I'm not qualified to judge, though, how successful they are so far. FWIW, when I hear people talk about VS Code, they appear to like it very much. But AFAICT, it has some way to go to catch up with all the functionality emacs has accreted over 30+ years. Also, there is an effort replace the old lisp engine inside emacs with GNU Guile, which is a JIT compiler that supports Scheme, ELisp, and Javascript. I have not tried it so far, but it might become possible to customize and extend emacs with Javascript in the not-so-distant future.

oblio 5y ago
Isn't the Guile effort practically dead? I remember hearing about it 10 years ago. It was actually started in 2000 and doesn't seem to have progressed since 2014: https://emacsninja.com/posts/state-of-emacs-lisp-on-guile.html https://emacsninja.com/posts/state-of-emacs-lisp-on-guile.ht... Plus, even if it's finished, will it get any traction in the ecosystem? Will the ecosystem start moving to it to take advantage of its unique benefits? Who knows? Bonus: Have you heard of GNU Hurd? :-)
- krylon 5y ago
  I honestly don't know about the state or progress of Guile Emacs. I know it exists, but I haven't followed it beyond that. Assuming it gets "finished" (is any software ever finished?), it should be no-brainer as long as it provides backward compatibility with old elisp code. And open up the emacs ecosystem to Scheme and Javascript, which could make it much more attractive to newcomers. But, as they say, I'll believe it when I see it. The trouble with Hurd, IMHO, is that I've run out of jokes. We used to joke that it would run Duke Nukem Forever out of the box, but that one actually got finished. Then it was Perl 6, but that has arrived, too. Star Citizen maybe?
- r-zip 5y ago
  Yes, Guile Emacs got abandoned, at least the last time I checked.
stjohnswarts 5y ago

Zababa 5y ago

Not exactly, VSCode is more of an editor that can accept very advanced plugins. The "virtual JavaScript machine with a standard library for writing graphical (text) applications." is a web browser.