4 ms·

This sounds like it's not written by an actual Emacs user... and the fact that I can tell points to the real fundamental problem of Emacs: it's not a text edito

by kqr 5y ago

This sounds like it's not written by an actual Emacs user... and the fact that I can tell points to the real fundamental problem of Emacs: it's not a text editor but the real thing it is is so complicated it finds it easier to market itself as a mere text editor. What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. It's more like the JVM than like Notepad. It just happens to come bundled with a text editor (and a file manager, and a calculator, etc) as example applications. You're free to install a better text editor than the bundled example, and many people to (see the popularity of Evil, for example). But of course, this is a much more complicated point in space to sit in, so Emacs markets itself primarily as a text editor and we get confusion like yours as a result.

jimbokun 5y ago
> 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.
vintermann 5y ago
I never claimed to be an emacs user. I've used Linux exclusively at home since 2001, and I've never "switched" to it or vim, though of course I have a passing familiarity with both from such things as certifications or working on other people's machines. Of course I'm familiar with the "never leave emacs" meme, moon phase indicators and "what it needs is a good editor" etc. I even gave an example of it being used as a platform in my other comment here (proof general). But this was about its popularity relative to other editors, not relative to other scriptable framework things.
- varjag 5y ago
  Thing is the difference between Emacs undo tree and …other editors undo is way more than the key binding. Your comment barely scratches the surface of the issue.
krylon 5y ago
This is something I wish someone had told me 20 years ago when I first started using emacs. The whole "it's a text editor, but also it's not really a text editor"-thing was very confusing initially. ... Although, now that I think about it, being told this mind-blowing revelation about the emacs nature might have confused me even more. What I love about emacs is that I have a variety - an extensible variety! - of programs under one roof, so to speak, sharing the same - customizable! - keyboard shortcuts that comfortably integrate with each other. I think the main problem in "proselytizing" emacs to potential new users is that it is kind of the C++ of text editors, in the sense that it takes a very big up front investment that does pay off in a big way if you persist, but getting to that point took - at least for me - a multi-year commitment. It is hard to sell someone on that unless they want to do it anyway. I did it out of fun and curiosity, but if you view it as an investment in purely transactional terms, it's hard to sell.
- chipotle_coyote 5y ago
  You just succinctly described why my annual attempts to learn Emacs never actually go anywhere. As much as I like the idea of an all-purpose text processor construction kit, even with "starter kits" I spend a week trying to configure various languages to a point that I'm happy, find myself copying, pasting and tweaking Lisp code, invariably find weird conflicts that lead me to do web searches (which may find more Lisp code, which may be a decade out of date), and so on. I don't doubt that if I kept at it I'd eventually reach nirvana, but I frequently find myself thinking "this was just so much easier in Vim" -- and any time anything can be described as "easier in Vim", it feels like a sign of a UX problem. :)
  - krylon 5y ago
    sigh I cannot blame you. And if vi makes you happy, I want you to enjoy the heck out of it. Between discovering emacs and making it my editor of choice I spent a few years using vi heavily, and to this day, I reflexively use it for quickly editing config files. Regarding emacs, all I can say is that, in my experience, it gets better if you really stick with it for a while. The payoff is huge if you put in the time. But time is limited resource, vi gives you a payoff much faster, so ... like I said, if it works you, don't fix what ain't broken. I love Emacs, but I also love the variety of editors programmers can choose from. With programmers' editors, as with society as a whole, I consider diversity an advantage.
srcreigh 5y ago
It's an early web browser. Elisp is an early JS. Viewing documents is just a little more complicated (download packages, sync stuff down using Git, etc)
bigbillheck 5y ago
In a couple months I'll have been using emacs for 30 years, and it seemed like a pretty good summary to me. In that time the closest I've gotten to using any of the lisp stuff is setting some variables in my .emacs file. (and it's been fewer of those as the year go by)
kamaal 5y ago
>>What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. It's more like the JVM than like Notepad. Well then in that case, ship a better Lisp than emacs lisp?

by kqr 5y ago

jimbokun 5y ago

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

vintermann 5y ago

I never claimed to be an emacs user. I've used Linux exclusively at home since 2001, and I've never "switched" to it or vim, though of course I have a passing familiarity with both from such things as certifications or working on other people's machines. Of course I'm familiar with the "never leave emacs" meme, moon phase indicators and "what it needs is a good editor" etc. I even gave an example of it being used as a platform in my other comment here (proof general). But this was about its popularity relative to other editors, not relative to other scriptable framework things.

varjag 5y ago
Thing is the difference between Emacs undo tree and …other editors undo is way more than the key binding. Your comment barely scratches the surface of the issue.

krylon 5y ago

This is something I wish someone had told me 20 years ago when I first started using emacs. The whole "it's a text editor, but also it's not really a text editor"-thing was very confusing initially. ... Although, now that I think about it, being told this mind-blowing revelation about the emacs nature might have confused me even more. What I love about emacs is that I have a variety - an extensible variety! - of programs under one roof, so to speak, sharing the same - customizable! - keyboard shortcuts that comfortably integrate with each other. I think the main problem in "proselytizing" emacs to potential new users is that it is kind of the C++ of text editors, in the sense that it takes a very big up front investment that does pay off in a big way if you persist, but getting to that point took - at least for me - a multi-year commitment. It is hard to sell someone on that unless they want to do it anyway. I did it out of fun and curiosity, but if you view it as an investment in purely transactional terms, it's hard to sell.

chipotle_coyote 5y ago
You just succinctly described why my annual attempts to learn Emacs never actually go anywhere. As much as I like the idea of an all-purpose text processor construction kit, even with "starter kits" I spend a week trying to configure various languages to a point that I'm happy, find myself copying, pasting and tweaking Lisp code, invariably find weird conflicts that lead me to do web searches (which may find more Lisp code, which may be a decade out of date), and so on. I don't doubt that if I kept at it I'd eventually reach nirvana, but I frequently find myself thinking "this was just so much easier in Vim" -- and any time anything can be described as "easier in Vim", it feels like a sign of a UX problem. :)
- krylon 5y ago
  sigh I cannot blame you. And if vi makes you happy, I want you to enjoy the heck out of it. Between discovering emacs and making it my editor of choice I spent a few years using vi heavily, and to this day, I reflexively use it for quickly editing config files. Regarding emacs, all I can say is that, in my experience, it gets better if you really stick with it for a while. The payoff is huge if you put in the time. But time is limited resource, vi gives you a payoff much faster, so ... like I said, if it works you, don't fix what ain't broken. I love Emacs, but I also love the variety of editors programmers can choose from. With programmers' editors, as with society as a whole, I consider diversity an advantage.

srcreigh 5y ago

It's an early web browser. Elisp is an early JS. Viewing documents is just a little more complicated (download packages, sync stuff down using Git, etc)

bigbillheck 5y ago

In a couple months I'll have been using emacs for 30 years, and it seemed like a pretty good summary to me. In that time the closest I've gotten to using any of the lisp stuff is setting some variables in my .emacs file. (and it's been fewer of those as the year go by)

kamaal 5y ago

>>What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. It's more like the JVM than like Notepad. Well then in that case, ship a better Lisp than emacs lisp?