Emacs has got to be one of the most misunderstood pieces of technology. It's often made fun of [1], just because of this misunderstanding. Saying Emacs is an editor (mostly), is like saying a smartphone is a phone (mostly).
Emacs is actually an appliction framework (and a Lisp machine) with a unified interface where one application can share data with other applications via "buffers" very easily because the basic data is text (no proprietary or fancy datastructures that can get outdated at some time). With this underlying structure (plus with the integrated programming language Lisp) you can connect, combine, configure (to your liking) every application within Emacs easily. In non-Emacs world, using isolated apps (islands), I'd "beg" the dev teams to add this or that feature to make it more productive [3]. Not so in Emacs-land, where I can change every aspect of an app within minutes.
I have legacy tools / apps that were discontinued, and my data is stuck in those formats [2], and I don't have the time to migrate those documents.
Emacs is here to stay. And offers many apps (packages) for many use-cases: org-mode for project management, task-management, taking notes, writing complex documents, creating technical documentation with inline images, ascii tables, with embedded code (that can get run via org-babel); lsp-mode which transforms Emacs into a decent IDE; calc for doing basic to complex calculations within Emacs (documents); org-babel for doing literate programming; eshell for using your shell within emacs; mu4e which is a very good email client (says someone who used to use MailMate and was thrilled I could use keyboard shortcuts to control lots of aspects of my email client), and many more.
Emacs is the tool that will grow on you, and it will get better the more you learn about how to configure it.
---
[1]: "a great operating system, lacking only a decent editor"
[2]: EccoPro PIM from the 90s, AskSam (full text database) from the 90s, NoteMap (outliner), MS Access databases (from the 90s/2000s) with old format, and many many more.
[3]: Whenever I liked an app, I'd quickly start writing with dev teams back and forth in forums or via email. Bear.app, Ulysses.app, iA Writer, DevonThink, etc. Constantly writing to the dev teams, asking to include this or that feature.
> "a great operating system, lacking only a decent editor"
That joke seems to imply a perfect understanding that it's more than a text editor. It is, however, referred to as "The Emacs Editor" in its documentation and "an extensible, customizable, free/libre text editor — and more" on its official website, which could lead to some confusion about its primary purpose if that's not editing text. I do begrudgingly use Emacs as my main editor because that's what the communities of the languages I like use, but I do find the editing experience to be sub-par compared to other editors I've worked with, and I find that there are better external alternatives to any of the common elisp applications, barring org-mode.
The thing is that editing/text-navigation modes are so universally useful that it makes perfect sense to make a supposed “OS-level” text editor. How many plugins, extensions, etc. are there so that people can use Vim bindings in web browsers, IDEs, the window manager, etc.?
I use evil-mode and that has alleviated any complaints I had about the editing experience. But then again, the modal nature of vi is how I think about editing text.
I generally agree with your statement, but the primary thing that prevents me from switching to a more modern editor is counsel/ivy. I really wish that VS Code or others offered a similar experience of filtering a buffer/project so quickly and easily. The editing experience of Evil with ivy is fantastic.
I just wish that things like autocomplete or debugging were easier to get right across languages...
The whole point of Emacs is: you get to change whatever you don't like.
Furthermore, why use Emacs as an IDE if you don't like it? Who cares what editor you use? Unless you use Emacs, then they make fun of you for using it, while relying on your efficient text processing skills to do refactoring.
Emacs being a platform within a platform is a feature. It comes with an extra benefit: it's a free (libre) platform. Completely shielded from corporate interests. There's no bullshit inside. No proprietary formats, no unnecessary network dependencies, no "X as a Service". Just a community of folks maintaining and expanding a parasitic OS that embraces interoperability and personal productivity above all.
When I realized how powerful Emacs is, how it enables me to create a very streamlined workflows in my day-to-day work, I realized I have no need at all for a crippled tablet (not naming the company) that won't allow me to use Emacs (or many other full-featured software), and that's when I put my fancy tablet on eBay for sale realizing that all the apps that I used on it created yet more islands of isolated data that I will have time and effort to get that out of those formats.
Not many fellows are aware of the value of the freedom to use a platform and tools that are open, that give you the freedom to do what you want with it. They see a fancy interface, and they are sold, not seeing the long term costs, the loss of control, the crippled-ness, the trajectory of the whole industry towards a vision that takes away many forms of freedom that constituted personal computing as we know it.
I agree, and I am frequently impressed by the tools people have built on this platform.
But I think the "it's a great operating system" line is wrong because it has underinvested in scheduling and process management.
> "a great operating system, lacking only a decent editor"
I've seen this thrown around when people joke why vim is better than Emacs and i think it's funny. But, seeing that Emacs has evil-mode, which is basically an implementation of vim on top of the said "operating system", i'd say it's false. Or ironic :D
As a vim user who recently migrated to emacs, this is 100% true. Emacs is now, among other things, a superset of Vim.
Before using Emacs, I had always read that emacs has a steep learning curve. I found this not to be case since the vim emulation was so good and so complete, I was reasonably productive pretty quickly even though I obviously have a ton to learn about emacs.
How can this work? Let's say I am developing a spreadsheet. Each cell has a formula, and it has a rendered text version. How can this work in Emacs? I want there to be a "underlying" strongly typed version of the data which is rendered, but Emacs forces them to be the same.
Unix (with pipes) also works with plain bytes, but many pipes are not necessarily rendered. Given that emacs is inherently visual, because you see the buffer if you're working with it, why can't there be data structures?
See [0] for examples of spreadsheet support in Org Mode (which, while often discussed as a thing of its own, is still part of default Emacs installation).
Basically, your table is drawn as text (with Emacs automatically managing its layout, and providing various shortcuts for larger manipulations like inserting or swapping rows/columns). Formulas are recorded as text below the table. They get recomputed on demand, or can be made to recompute on each edit[1].
[1] - https://orgmode.org/org.html#Advanced-features describes a bunch of features, including recomputation of select rows on edit/navigation, as well as marking which rows are names of columns or cells vs. data.
Emacs comes with a pretty good plain text spreadsheet. I have not figured out how to use it for large amounts of data (caped at 999 rows) but it's way more powerful than "your favorite spreadsheet software" as it allows for both calc and elisp formulas. All in plain text yeah, types are as strong as elisp's. And maybe I am wrong, but spreadsheets are not famous for strong types. I have horror stories to share on that respect.
I guess you could strong type by using a type cast formula with elisp...
Which is exactly the reason why... VSCode is winning the editors war.
The main difference is that it chose javascript instead of lisp as its universal language, which, in the current world, is a much better choice for adoption.
Also, saying app can share data easily because the format is text buffer is either a tautology or a non-sequitur: not having a defined format can't be broken, sure, but it also cannot be reliably used. ask anyone who had to maintain bash/awk/perl labyrinthine assemblies...
> The main difference is that it chose javascript instead of lisp as its universal language,
That is not the main difference. The main difference is that Emacs can be extended on the fly. While VS follows the traditional plugin approach.
For VSCode to the have the same kind of extensibility it would have to allow opening an inspector on the _running_ instance. Click an element, jump to its source edit the source on the fly and have that change persisted. Or allowing your settings to patch (which by the nature of ES6 modules is not something you will be able to do).
The on the fly extension is crucial for quick QoL improvements to your workflow. You can spend 5 minutes writing a function instead of having to setup a project/plugin to something as trivial as say, copying a .env file and updating some values when you create a [git] worktree.
> Which is exactly the reason why... VSCode is winning the editors war.
The main reason why VSCode is 'winning' the 'editor' wars is because Microsoft is spending tons of money to build a great product. Emacs, vim, and other open source projects can't compete as they don't have nearly the same amount of resources. They have healthy communities and are thriving FLOSS communities but people who are scratching an itch won't be writing monthly tours of new features like https://code.visualstudio.com/updates/v1_52 f/e.
> ask anyone who had to maintain bash/awk/perl labyrinthine assemblies...
Text in Emacs is richer than plain-text. You have overlays to annotate it with metadata, text properties, you can attach callbacks to it, etc. It is only at the boundaries that you have to resort to plain-text for interoperability purposes.
This means it is easy to inter-op with CLI utils but present a richer, more powerful interface. Ej. dired uses ls.
> The main difference is that it chose javascript instead of lisp as its universal language, which, in the current world, is a much better choice for adoption.
That at best bifurcates the community (possibly along the age lines). I for one consider it to be a bad choice for me personally. JavaScript ain't a particularly pretty language. And it's nowhere as nice as Emacs Lisp.
> saying app can share data easily because the format is text buffer is either a tautology or a non-sequitur
I'd agree, though with caveat that an Emacs buffer is not just an array of text. It's an array of text with bells, whistles, and a semantically well-designed API layer. This lets extensions to mostly compose nicely.
But I'd say the more important feature is that nothing is sandboxed. That means extensions can detect and work around potential conflicts with other extensions, up to the point of extending or replacing any function such conflicting extension uses (though with proper extension design - which is by this point a part of Emacs culture - this is rarely needed). It's easy for any extension to expose an API layer for interop, and Emacs itself provides enough of an API surface that usually you don't even need to do that explicitly.
More importantly, I myself can trivially extend or fix extensions as well. Something conflicts and errors out? Flip a debugger trap, wait for it to error again, poke around the source, find the culprit, patch it in your config. Granted, you need a passing familiarity with Emacs Lisp for that (though IMO, one should consider getting comfortable with Emacs Lisp a part of becoming a power user of Emacs). But you can do that, quite easily, and the entire environment supports you in doing this.
> The main difference is that it chose javascript instead of lisp as its universal language
The main reason is that it's backed by Microsoft, both because of the investment that provides and the visibility it provides.
JavaScript over Lisp probably helps, but if VSCode had Visual Basic as it's extension language it would still be doing strong, and not because VB is a good or popular language independently.
In what sense is there a "war"? That's a serious question. Emacs, VS Code, and quite a few of the other popular editors are open source. You can download them and use them. I have both Emacs and VS Code on my machine, and I use both of them, but for different purposes.
Now, if you wanted to talk about a war between open source and traditional closed-up-tight, walled-garden commercial software, I could get on board. It's really hard for me to understand your framing when you have freely available products that are not in any way exclusive.
On your other point, if I were to speculate, I'd say VS Code's main advantage is that it doesn't have a 1970's graphical interface. Port GNU Emacs to Monaco, give it some good default settings, and see what happens to adoption.
VSCode is winning the war that Sublime Text (and it's python api) was winning a few years back (and perhaps Notepad++ before that). A few years from now VSCode might still reign supreme... or it might not. If you're fine jumping to the next winner every few years, great. If you'd rather just invest in one editor platform and stick with it for a couple of decades, and know you can rely on it to stick around and be supported that long... well, you might want to take a look at emacs.
I think that elisp is one of the many a strengths of Emacs, along with it's strong extensibility, customization, and general user freedom. I think language choice is a smaller part of the pie compared to Microsoft's backing, networking effects within companies, and visual appeal and design.
However, I do agree with you that Emacs onboarding process can be difficult if you don't know lisp, in that you have to now learn a new language and the API for interacting with the editor. That is why some friends and I recently decided to embed JavaScript/TypeScript into Emacs as a means of controlling the editor [1]. We will see if we can prove you right.
This looks interesting and I want to use it. It seems to not be available on melpa, and the installation instructions for linux are missing, though. Are there any instructions for installation on linux that I miss? Apart from the cloning and tinkering that I will inevitably do if there is no easier way.
Sure, emacs is an OS [1], you can write any kind of programs for it.
On the other hand, you can do symbolic calculus in Scheme - see, for example, MIT Scheme-based Structure and Interpretation of Classical Mechanics (which, incidentally, is perfectly usable from inside emacs).
Of course, in this example, the symbolic calculus functionality is distributed with the OS, or arguably even as part of it, which I guess is a bit more rare than simply having the option of installing it.
If it's Android you can at least for the moment get Emacs on there using Termux. That's what I do - and it works pretty well. It might also be possible via UserLAnd, although I have not tried UserLAnd personally.
It seems like iSH on iPhone may provide similar ability (again do not have direct experience) although it seems unclear at the moment how long it will be able to remain available.
Who in his right mind would use an editor that cannot even do symbolic integration?
Joking aside, I suspect that this is mostly due to two factors:
1. Emacs was used by a lot of smart people, and one of them, David Gillespie got carried away a bit.
2. Thirty years ago, when David Gillespie first started working on calc, emacs lisp (despite at the time lacking even floating points numbers IIRC!), was probably one of the most expressive fairly widely deployed languages around, particularly for the type of symbolic manipulation you need to do for computer algebra. And unlike other things that were used by smart people 30 years ago, emacs still sticks around, so survivorship bias also plays a role.
It's a bit like asking why Windows has a calculator :).
Emacs is best viewed a Lisp execution platform with a built-in text UI. Much like it has a "c++ app", "terminal app" and "compile this" app, it also ships with a "calc app" (literally called "calc"). Since it was being used by lot of mathy people for lot of mathy stuff, it ended up being a proper scientific calculator application.
(Also, Lisps are inherently friendly for doing any kind of symbolic calculations. A Lisp system is one of the least surprising places to find a symbolic integrator in.)
Emacs is best understood not just as an editor, but as an integrated computing environment promoting user freedoms to the fullest extent possible in a manner naturally integrated with its user interface and extensibility. In that sense, it shouldn’t be the least bit surprising to see the kind of in-built application suite one would expect from an operating system or desktop environment. One must also remember that historically the most common computer (power) users were academics, and not “software developers” — so expect a lot of scratches for their itches.
It’s a bit like asking why does bash come with a utility like awk or bc; it’s equally natural.
M-x doctor RET
I am the psychotherapist. Please, describe your problems. Each time
you are finished talking, type RET twice.
Why does Emacs need Symbolic Integration?
What do you think?
I don't know, just answer the question!
Why do you say you do not know just answer the question?
[...]
Maybe you'll have better luck than I did with mine.
I think the Emacs doctor drilled down my insecurities down to a bad exam in school. (S)he ? claimed that his/her secretary will send me the bill, but I haven't been back so they must have forgotten.
Thanks for posting this. Not only it's an amazing story of scope creep, it also revealed a bunch of features I didn't know calc had (e.g. unit handling, arbitrary-size math).
thanks for the reference! love the final acknowledgement in there:
> Final thanks go to Richard Stallman, without whose fine implementations of the Emacs editor, language, and environment, Calc would have been finished in two weeks.
In general - developers use calculators all the time (most frequently via Google these days, but also via REPLs) so a dedicated calculator is a self-evidently useful widget for any editor. It’s is not essential fir a new editor in 2021 but considering emacs has had Calc for some time, it is worthwhile to make improvements to widely-used legacy software. Many emacs users have used Calc in lieu of alternative “developer calculators” like Octave, the R REPL, etc, so it’s not like Calc is an extraneous feature.
It’s uncommon for developers to deal with integral equations in their day-to-day work. But it’s obviously not unheard of - integral equations show up naturally in many domains of finance and engineering. I’ve had to deal with numeric integration on .NET in one of my jobs. Sometimes an exact symbolic solution is easier for the developer and the CPU than a numeric technique, so for a small handful of developers a symbolic integral calculator is a handy (if somewhat specialized) tool, and not just some bell-and-whistle.
GNU Emacs is a 36 year old tool that's been targeted at programmers its entire life, is built on an interactive Lisp environment, and actively encourages external improvements and contributions. The more interesting question is why _wouldn't_ it have that functionality.
I don't think it's a valid example. The discussion is about the default configuration, not about removing mouse scrolling from the code. It's a really big thread nevertheless...
A healthier approach is to have a separate non-Emacs app that can do symbolic integration, which can be run seamlessly from within Emacs.
Otherwise, with all its extensions Emacs starts giving the impression of an Apple-like walled garden, which is not a good comparison for a free software, no?
Readit News
Emacs is actually an appliction framework (and a Lisp machine) with a unified interface where one application can share data with other applications via "buffers" very easily because the basic data is text (no proprietary or fancy datastructures that can get outdated at some time). With this underlying structure (plus with the integrated programming language Lisp) you can connect, combine, configure (to your liking) every application within Emacs easily. In non-Emacs world, using isolated apps (islands), I'd "beg" the dev teams to add this or that feature to make it more productive [3]. Not so in Emacs-land, where I can change every aspect of an app within minutes.
I have legacy tools / apps that were discontinued, and my data is stuck in those formats [2], and I don't have the time to migrate those documents.
Emacs is here to stay. And offers many apps (packages) for many use-cases: org-mode for project management, task-management, taking notes, writing complex documents, creating technical documentation with inline images, ascii tables, with embedded code (that can get run via org-babel); lsp-mode which transforms Emacs into a decent IDE; calc for doing basic to complex calculations within Emacs (documents); org-babel for doing literate programming; eshell for using your shell within emacs; mu4e which is a very good email client (says someone who used to use MailMate and was thrilled I could use keyboard shortcuts to control lots of aspects of my email client), and many more.
Emacs is the tool that will grow on you, and it will get better the more you learn about how to configure it.
---
[1]: "a great operating system, lacking only a decent editor"
[2]: EccoPro PIM from the 90s, AskSam (full text database) from the 90s, NoteMap (outliner), MS Access databases (from the 90s/2000s) with old format, and many many more.
[3]: Whenever I liked an app, I'd quickly start writing with dev teams back and forth in forums or via email. Bear.app, Ulysses.app, iA Writer, DevonThink, etc. Constantly writing to the dev teams, asking to include this or that feature.
That joke seems to imply a perfect understanding that it's more than a text editor. It is, however, referred to as "The Emacs Editor" in its documentation and "an extensible, customizable, free/libre text editor — and more" on its official website, which could lead to some confusion about its primary purpose if that's not editing text. I do begrudgingly use Emacs as my main editor because that's what the communities of the languages I like use, but I do find the editing experience to be sub-par compared to other editors I've worked with, and I find that there are better external alternatives to any of the common elisp applications, barring org-mode.
I just wish that things like autocomplete or debugging were easier to get right across languages...
Emacs being a platform within a platform is a feature. It comes with an extra benefit: it's a free (libre) platform. Completely shielded from corporate interests. There's no bullshit inside. No proprietary formats, no unnecessary network dependencies, no "X as a Service". Just a community of folks maintaining and expanding a parasitic OS that embraces interoperability and personal productivity above all.
Not many fellows are aware of the value of the freedom to use a platform and tools that are open, that give you the freedom to do what you want with it. They see a fancy interface, and they are sold, not seeing the long term costs, the loss of control, the crippled-ness, the trajectory of the whole industry towards a vision that takes away many forms of freedom that constituted personal computing as we know it.
There is even a decent editor application available these days in evil[0].
[0] https://www.emacswiki.org/emacs/Evil
I've seen this thrown around when people joke why vim is better than Emacs and i think it's funny. But, seeing that Emacs has evil-mode, which is basically an implementation of vim on top of the said "operating system", i'd say it's false. Or ironic :D
Before using Emacs, I had always read that emacs has a steep learning curve. I found this not to be case since the vim emulation was so good and so complete, I was reasonably productive pretty quickly even though I obviously have a ton to learn about emacs.
How can this work? Let's say I am developing a spreadsheet. Each cell has a formula, and it has a rendered text version. How can this work in Emacs? I want there to be a "underlying" strongly typed version of the data which is rendered, but Emacs forces them to be the same.
Unix (with pipes) also works with plain bytes, but many pipes are not necessarily rendered. Given that emacs is inherently visual, because you see the buffer if you're working with it, why can't there be data structures?
Basically, your table is drawn as text (with Emacs automatically managing its layout, and providing various shortcuts for larger manipulations like inserting or swapping rows/columns). Formulas are recorded as text below the table. They get recomputed on demand, or can be made to recompute on each edit[1].
--
[0] - https://orgmode.org/worg/org-tutorials/org-spreadsheet-intro...
[1] - https://orgmode.org/org.html#Advanced-features describes a bunch of features, including recomputation of select rows on edit/navigation, as well as marking which rows are names of columns or cells vs. data.
I guess you could strong type by using a type cast formula with elisp...
The main difference is that it chose javascript instead of lisp as its universal language, which, in the current world, is a much better choice for adoption.
Also, saying app can share data easily because the format is text buffer is either a tautology or a non-sequitur: not having a defined format can't be broken, sure, but it also cannot be reliably used. ask anyone who had to maintain bash/awk/perl labyrinthine assemblies...
That is not the main difference. The main difference is that Emacs can be extended on the fly. While VS follows the traditional plugin approach.
For VSCode to the have the same kind of extensibility it would have to allow opening an inspector on the _running_ instance. Click an element, jump to its source edit the source on the fly and have that change persisted. Or allowing your settings to patch (which by the nature of ES6 modules is not something you will be able to do).
The on the fly extension is crucial for quick QoL improvements to your workflow. You can spend 5 minutes writing a function instead of having to setup a project/plugin to something as trivial as say, copying a .env file and updating some values when you create a [git] worktree.
> Which is exactly the reason why... VSCode is winning the editors war.
The main reason why VSCode is 'winning' the 'editor' wars is because Microsoft is spending tons of money to build a great product. Emacs, vim, and other open source projects can't compete as they don't have nearly the same amount of resources. They have healthy communities and are thriving FLOSS communities but people who are scratching an itch won't be writing monthly tours of new features like https://code.visualstudio.com/updates/v1_52 f/e.
> ask anyone who had to maintain bash/awk/perl labyrinthine assemblies...
Text in Emacs is richer than plain-text. You have overlays to annotate it with metadata, text properties, you can attach callbacks to it, etc. It is only at the boundaries that you have to resort to plain-text for interoperability purposes.
This means it is easy to inter-op with CLI utils but present a richer, more powerful interface. Ej. dired uses ls.
That at best bifurcates the community (possibly along the age lines). I for one consider it to be a bad choice for me personally. JavaScript ain't a particularly pretty language. And it's nowhere as nice as Emacs Lisp.
> saying app can share data easily because the format is text buffer is either a tautology or a non-sequitur
I'd agree, though with caveat that an Emacs buffer is not just an array of text. It's an array of text with bells, whistles, and a semantically well-designed API layer. This lets extensions to mostly compose nicely.
But I'd say the more important feature is that nothing is sandboxed. That means extensions can detect and work around potential conflicts with other extensions, up to the point of extending or replacing any function such conflicting extension uses (though with proper extension design - which is by this point a part of Emacs culture - this is rarely needed). It's easy for any extension to expose an API layer for interop, and Emacs itself provides enough of an API surface that usually you don't even need to do that explicitly.
More importantly, I myself can trivially extend or fix extensions as well. Something conflicts and errors out? Flip a debugger trap, wait for it to error again, poke around the source, find the culprit, patch it in your config. Granted, you need a passing familiarity with Emacs Lisp for that (though IMO, one should consider getting comfortable with Emacs Lisp a part of becoming a power user of Emacs). But you can do that, quite easily, and the entire environment supports you in doing this.
The main reason is that it's backed by Microsoft, both because of the investment that provides and the visibility it provides.
JavaScript over Lisp probably helps, but if VSCode had Visual Basic as it's extension language it would still be doing strong, and not because VB is a good or popular language independently.
In what sense is there a "war"? That's a serious question. Emacs, VS Code, and quite a few of the other popular editors are open source. You can download them and use them. I have both Emacs and VS Code on my machine, and I use both of them, but for different purposes.
Now, if you wanted to talk about a war between open source and traditional closed-up-tight, walled-garden commercial software, I could get on board. It's really hard for me to understand your framing when you have freely available products that are not in any way exclusive.
On your other point, if I were to speculate, I'd say VS Code's main advantage is that it doesn't have a 1970's graphical interface. Port GNU Emacs to Monaco, give it some good default settings, and see what happens to adoption.
However, I do agree with you that Emacs onboarding process can be difficult if you don't know lisp, in that you have to now learn a new language and the API for interacting with the editor. That is why some friends and I recently decided to embed JavaScript/TypeScript into Emacs as a means of controlling the editor [1]. We will see if we can prove you right.
[1] https://github.com/emacs-ng/emacs-ng
Create latex equations in calc! :D
On the other hand, you can do symbolic calculus in Scheme - see, for example, MIT Scheme-based Structure and Interpretation of Classical Mechanics (which, incidentally, is perfectly usable from inside emacs).
[1] http://www.informatimago.com/linux/emacs-on-user-mode-linux....
If it's Android you can at least for the moment get Emacs on there using Termux. That's what I do - and it works pretty well. It might also be possible via UserLAnd, although I have not tried UserLAnd personally.
It seems like iSH on iPhone may provide similar ability (again do not have direct experience) although it seems unclear at the moment how long it will be able to remain available.
On the tinier lib side there's bindat, to fiddle with binary data straight from elisp.
Joking aside, I suspect that this is mostly due to two factors:
1. Emacs was used by a lot of smart people, and one of them, David Gillespie got carried away a bit.
2. Thirty years ago, when David Gillespie first started working on calc, emacs lisp (despite at the time lacking even floating points numbers IIRC!), was probably one of the most expressive fairly widely deployed languages around, particularly for the type of symbolic manipulation you need to do for computer algebra. And unlike other things that were used by smart people 30 years ago, emacs still sticks around, so survivorship bias also plays a role.
Emacs is best viewed a Lisp execution platform with a built-in text UI. Much like it has a "c++ app", "terminal app" and "compile this" app, it also ships with a "calc app" (literally called "calc"). Since it was being used by lot of mathy people for lot of mathy stuff, it ended up being a proper scientific calculator application.
(Also, Lisps are inherently friendly for doing any kind of symbolic calculations. A Lisp system is one of the least surprising places to find a symbolic integrator in.)
Hence the old joke "Emacs is a fine OS, but its text editor sucks."
It’s a bit like asking why does bash come with a utility like awk or bc; it’s equally natural.
https://pubs.opengroup.org/onlinepubs/9699919799/
How many other meme modes exist? I dug up the earliest commits I could find, and apparently one of the earliest hooks was "protect-innocence-hook": https://twitter.com/theshawwn/status/1327459335245422597
If the buffer's filename is "sex.6", it asks whether the user is over 18. If so, it renames the buffer to "celibacy.1".
Apparently it was in the file lisp/play/meese.el. Emacs archaeology is more fun than it should be.
> Final thanks go to Richard Stallman, without whose fine implementations of the Emacs editor, language, and environment, Calc would have been finished in two weeks.
:D
It’s uncommon for developers to deal with integral equations in their day-to-day work. But it’s obviously not unheard of - integral equations show up naturally in many domains of finance and engineering. I’ve had to deal with numeric integration on .NET in one of my jobs. Sometimes an exact symbolic solution is easier for the developer and the CPU than a numeric technique, so for a small handful of developers a symbolic integral calculator is a handy (if somewhat specialized) tool, and not just some bell-and-whistle.
GNU Emacs is a 36 year old tool that's been targeted at programmers its entire life, is built on an interactive Lisp environment, and actively encourages external improvements and contributions. The more interesting question is why _wouldn't_ it have that functionality.
Interestingly, nowadays it's really difficult to convince people to add new features, like enabling mouse scrolling by default [1].
[1] https://lwn.net/ml/emacs-devel/20200906133719.cu6yaldvenxubc...
I have not had to use the more advanced features. I did not know that they were there. Now I know, perhaps I do need them?
Elisp is the most popular Lisp in the world.
Why wouldn’t you want to improve it?
I'm a graphics programmer and I use Emacs' in-built RPN calc for its linear algebra capabilities almost daily.
Otherwise, with all its extensions Emacs starts giving the impression of an Apple-like walled garden, which is not a good comparison for a free software, no?