The Emacsen family, the design of an Emacs and the importance of Lisp (2023)
emacsconf.org
emacsconf.org
My advice to people when editor wars come up is that going deep on something is more important than going deep on the right thing. emacs versus vi? No strong opinion. I happened to learn emacs first and would be repeating a lot of labor to go as deep on vi.
(... But I do tend to give a slight nudge in the direction of something of that ilk because relative to say, VS code... Those editors have already stood the test of time, they aren't beholden to one owner, and while past performance is not proof of future expectations, there's a lot of people heavily invested in keeping both of them alive and thriving).
Speaking as someone who used vim for 10 years before getting sniped by Emacs (ten years ago.. shit I'm getting old):
vim isn't as deep as Emacs, it's not even close. vim is only as deep as evil-mode. In fact, vim has a UX paradigm that's out-of-the-ordinary, and that's it.
That's why in Emacs, modal editing is just another minor mode..
https://lem-project.github.io/ https://github.com/lem-project/lem
Licences like GPL optimise community freedom: they give each user the freedom to do anything except restricting the freedom of others.
Think of it like local vs global optimisation.
MIT doesn't give people a freedom to restrict because that isn't a freedom. The restriction is always done by the legal system. The GPL is just an attempt to stop the legal system from interfering in the market to restrict user freedom. So both licenses are actually communicating to a 3rd party (a judge) under what circumstances they should restrict the freedom of others. GPL says to stay out of it as long as people are sharing their source code and MIT says get involved sometimes/its complicated.
It isn't a practical difference, but it is philosophically important. The amount of personal freedom both licenses give is technically quite similar.
What many free software advocates actually want is a world without copyright on software. It's copyright that frames copying as stealing. In a world with copyright, the only way to counter that is copyleft. The fact GPL can also enforce inclusion of source code is a nice side effect of copyleft. But ultimately what we want is a world where software is shared, treated as knowledge and not as a product.
MIT style licences are just not good enough. That software could still end up in some copyright protected proprietary product one day and then, yes, someone could accuse me of "stealing" their property, which contains our software.
Some of them sure. The subset of them who are GPL advocates are simply confused though. GPL is not possible in a world without copyright. In a world without copyright I can release software, which can be written from the ground up or be based on something open source, doesn’t matter, and not share the code with anyone. Just the binary. I can also create AWS based on open source software and nothing like AGPL will stop me from providing proprietary services based on it.
If you want to see an argument from someone who opposes copyright, but has more consistent views on the matter, I recommend this piece: <https://github.com/BurntSushi/notes/blob/master/2020-10-29_l...>
And the reason I pointed to the fallacy is that multiple people in this thread suggest that making a proprietary product based on open source software constitutes taking something away from users of this software. This is illogical. They still have the original. The only person who loses in this situation is the original author, not the users.
You and the author appear to be the same guy. To be sure, the piece itself is an academic exercise hypothesizing a world in which the MIT license were law. And in such a world, the GPL gestapo would continue railing against opaque binaries even if those binaries were shameless but legal ripoffs of someone's hard work.
If I took emacs, modified it to be thread-safe, and distributed it as an opaque binary, John Q. Emacs User retains his thread-unsafe version but now knows there's something better out there which he can't iterate on. You can say this knowledge isn't a real "loss," but that would be dismissing the concept of opportunity cost.
We are not. We’re not even on the same continent.
I think you are confused. We don't want the GPL. The GPL is a pragmatic solution to make software free in a world with copyright.
Licences like MIT do absolutely nothing up further this goal. They don't even try to do it today even though we know it can be done. It seems convenient for software you might use now, but to contribute to it? It doesn't give developers any guarantee that their work will be received as free software by future users. You're essentially working for corporations for free. I want my work to be available for everyone.
I assure you GPL doesn't either. You can jump up and down furiously waving GPL all you want. Nothing short of a paid legal team would enforce it.
MIT and similar are simply roundabout ways to make it public domain.
Whilst yes, you could technically say 'well, if the user wants to know what this software is doing, they can just disassemble it', I'd consider that malicious compliance. It's like listing ingredients by their scientific names (like 'Arachis Hypogaea' instead of 'peanut').
I can. The guy giving away the ice cream is destroying the market. You can't compete against free. If programmers would stop surrendering their labor, personal data resellers like Google and Facebook wouldn't be our primary means of making a comfortable living. Say what you will about Microsoft's monopoly in the 90s. At least they took your money with your eyes open.
The irony of course is free software zealots are pissed at the free ice cream guy for completely different, and I agree with you, utterly stupid reasons.
But the issue of non-GPL software is the person on the receiving end might want to contribute, be technically able to contribute and indeed need to contribute to be able to keep using the software ... but then be blocked for legal reasons. The GPL doesn't care if you sell software or give it away or whatever, it is all about protecting freedom over time after the initial installation has happened.
The thing that makes the ice cream analogy ok is that the ice cream is literally synthesised into your body and comes under your complete control. If the ice-cream seller retained any sort of control over the ice cream after you'd ingested it that would be a serious problem! Both technically and morally. The GPL is aligning what happens in software to the analogy.
The point of the MIT license is to make it easier to link it to proprietary software. It is setting up a situation where users will not be free. In and of itself it isn't a bad license; it just doesn't protect freedom and it can be used in ways that block people from contributing. By design.
If you expect people to treat MIT licensed software as GPL licensed software, then they should be licensing it under the GPL. That they aren't implies that the intent is different.
News flash buddy. OSS devs, college and graduate students mostly, are clueless about the distinction and select whatever license tickles their fancy from GitHub's dropdown menu. They see a lot of MIT licenses floating around, recognize "MIT" as a good university, and figure they can't go wrong with it. They, like most normies, don't see how "freedom" figures into software at all. All they care about is getting a little shine before they join a FAANG after graduation.
As for why someone who does understand the distinction would choose MIT over GPL, ask Linus about why he'd "never want anything to do with the FSF" after being told to switch to GPLv3. Yes, MIT versus GPL is not the same as GPLv2 versus GPLv3 but the general concepts are the same.
> ... ask Linus about...
Linus uses GPLv2. I personally see merit in the argument that v2 is better than v3. Neither is MIT.
If you want to use the GPL license and not associate with the FSF then cool. If Linus wants to do that, also cool. The issue is the license, not if you want to work with the FSF. The GPL also grants users freedom from the FSF.
No. It is setting up a situation where users can choose between a free option A and a proprietary option B based on A. Being sad about A being too liberal is suggesting it’s more important for you that B doesn’t exist than that A exists.
> If you expect people to treat MIT licensed software as GPL licensed software,
I don’t. Contrary to GNU and FSF websites, GPL is not a synonym for freedom. Most people, outside of GNU-centric places like this post about Emacs, prefer more liberal licences.
That is the big difference between MIT and GPL. With MIT licensed software, sometimes you have software that you can't legally adjust (or help others adjust). With GPL ... I mean it might be technically possible with some wildly creative approach but I haven't heard of such a thing.
> Most people, outside of GNU-centric places like this post about Emacs, prefer more liberal licences.
Controlling someone else's computer through legal means isn't liberal. I'm sure a liberal could call for that and accept a little ideological impurity.
If software is property, it has a new owner after it is sold and they can do what they like with it. That isn't what copyright does, it creates some sort of Frankenstein permanent-rent concept where the owner often doesn't maintain anything that is at odds with technical and market realities, relying heavily on the prosecution of victimless crimes. Which although arguably a desirable thing (I don't think so myself though) is illiberal.
Really? The MIT license explicitly allows you to "modify" the software without restriction.
I'm no lawyer, but it isn't even obvious to me that you have to MIT license a binary created directly from MIT licensed source code. "Software" seems to be the source code and therefore the binary probably isn't a copy or substantial portion of the MIT licensed program. Unless lawyers are redefining words on me it looks like I can compile MIT licensed source and distribute it under whatever alternate license I like.
But regardless, if the point of the license is to enable creating proprietary software, it is no stretch at all to speculate that it'll be used to create proprietary software.
I really, really want a graphical emacs. By that I mean, I want an emacs with graphics, not an emacs in windows. I want to easily be able to draw stuff.
I ran into this the other day, I like to dabble in emacs, and I had a list of results I wanted to make a quick chart. I ended up dumping it out in a simple CSV, and copy/pasting that into a spreadsheet, and hitting "chart".
Would have been nice to go (line-chart my-list) and have a window pop up with reasonable defaults. And be able to print it to a PDF.
emacs has some SVG support, but I guess its maintainer whim whether you get it or not, I wasn't able to easily get it working on my Mac. That could be a start. But something "nicer" would be, you know, "nice".
https://sqrtminusone.xyz/posts/2021-05-01-org-python/
(the very first screenshot is Emacs)
But so many of the things I now rely on -- company mode, treemacs, vertico, etc. are not there. The value in Emacs is the huge community of things.
Also I had some instability each time I tried it -- buffers filling up with Common Lisp backtraces, etc.
Still I really want to see some advancement in this arena, because the actual implementation of GNU emacs leaves a lot to be desired in 2024. The packages overtop of it are nice, but the core editor blocks and pauses too much.
try C-x d aka M-x filer?
Useful though.
[1] https://web.archive.org/web/20221002093520/https://groups.go...
[2] https://web.archive.org/web/20210407151341/https://discuss.a...
The Deuce Editor Architecture (2014) - https://news.ycombinator.com/item?id=40117075 - April 2024 (6 comments)
The good things: editing works, slime works, access to all my Quicklisp based libraries and projects. The bad things mostly involve limited Lem functionality because I rely on many eLisp libraries like treemacs, etc.
I really like the speed, and having everything in Common Lisp is fun. I was using Roswell to build Lem from source, and I really liked the project’s setup, build process.
Try C-x d in Lem (Alt-x filer) https://lem-project.github.io/usage/usage/#filer---project-e...
Building the sdl2 version, there is no luck finding libSDL2_ttf, so I'll be trying the ncurses version.
Looks pretty snappy so far.
I only know that because when using Emacs on the Steam Deck using the menu bar is a little easier than doing input using Hacker Keyboard on my phone passed to the Deck using KDE Connect.
- Rune (https://github.com/CeleritasCelery/rune) - A re-implementation of Emacs but in Rust (like Remacs, but actively developed)
- Pimacs (https://github.com/federicotdn/pimacs) - Same, but using Go (created by me, but developed in a very slow pace)
Of course, it could be a foundation to build on, I dunno.
EDIT: yes after watching the presentation, it has a modal/vi type mode
Although I wish they’d explore the Kakoune/Helix style of editing too, which I think will become a major competitor to Vim (and I personally prefer it myself).
However, I am also worried that Lem won’t gain any traction because the Emacs ecosystem is just too vast and has too many killer apps (Magit, OrgMode, Dired, the amazing built-in Help/Documentation - to name a few).
But it may very well become a modern Emacs alternative if they focus on better user experience, leave behind some idiosyncrasies of the past and create great alternatives or ports of Emacs’s most appreciated plugins. There is a great opportunity in starting from scratch, but I guess it is also a huge challenge to compete against decades of development, a huge community and a rich ecosystem.
I'd hope that a fresh emacs from scratch would just ship with something close to what those provide.
In the end my biggest beef with emacs these days is just the terrible lack of multithreading, bringing long pause and startup times. Most of my problems in the past have been rectified. Emacs 29 is really quite delightful and much easier to manage than ever before.
Lem has a wip Git mode: see status, stage files/hunks, commit, interactive rebase, basic hg and fossil support. (I added it)
It's WIP and undocumented yet (don't worry I'll document when ready, I love documentation ;) ) Use
M-x lisp-eval-string RET (ql:quickload :lem/legit)
M-x legit-status or C-x g
Lem has a directory mode with some actions: sort (name, mtime, size), mark by regexp, rename, delete, find files…)
Lem has a LSP system,
something like projectile (M-x project-find-file, M-x project-switch etc, still inferior but nearly there and easy to extend)
images: yes (the SDL2 version). It can display games (M-x tetris, it can run a real game engine)
evil: great vim layer, no leader key. I didn't see a discussion about that, you should come and ask ;)
and no:
GUI buttons: that's not a UI choice I guess, so no
no org-mode support yet, although it has an Emacs RPC, so the idea is to use it to bring org-mode.
not asked, but good to know:
it has a wip Git mode: see status, stage files/hunks, commit, interactive rebase, basic hg and fossil support. (I added it)
Which video codec? Originally webm could contain only VP8, but nowadays it can also contain VP9 and AV1. It's possible that Apple only implemented VP8 (https://caniuse.com/webm implies that it has implemented VP8 and VP9 but has VP9 disabled by default); if this video uses a newer codec, it won't work.
https://sachachua.com/blog/2024/01/2024-01-28-yay-emacs-clos...
What he probably meant, that GNU Emacs (1984-...) was based on the code of another Emacs implementation, Gosling Emacs, which also had a commercial version.
The original EMACS was developed at MIT, 1976, by Guy L. Steele Jr. and David Moon.
If it's just because hacking is fun, then by all means have a blast. But if the goal is to compete with Emacs, consider instead setting the target at something with far greater popularity than Emacs.
(When I was starting out in software development, almost all of my colleagues used this. Now just a footnote.)
And Emacs will still be around.
What does that even mean? Both editors have large&strong communities. I don't see them going anywhere.
Worth noting is that LSP came from Microsoft as part of their efforts to build a better editor experience; and its integration with VSCode is largely unparalleled.
For example: in VSCode the user doesn't have to understand how to install a language server, it just automagically suggests allowing it to install one for you. In Emacs, if you're using the official distribution you will have eglot, whose developers specifically refuse to add that functionality. If you're savvy enough you can install lsp-mode and it will add that functionality, but at that point you may as well just install the language server yourself.
And about magit: it's a beautiful piece of software, it truly is. It's also hot garbage with large repositories hosted on Windows. I simply cannot use it for work because every operation takes around a minute to resolve, which locks up Emacs entirely. Again, here VSCode shines because the default git integration is pretty good, and there are extensions that make it excellent.
For these reasons, and more, I always recommend VSCode to new developers and don't recommend Emacs. Emacs is for people who want to make editor customization a _hobby_.
I can understand this not being friendly for some users, but on most systems that people are using Emacs on, software is installed through a system package manager and not downloaded and unpacked into ${HOME}. I do not want software that isn't the system package manager to install LSP servers.
Maybe this is more of an issue for people using Emacs on Windows, since there is no system package manager, and people are less likely to understand how to install stuff.
I disagree. I use it for org mode to take notes, track time, and write documentation. I use it with SLIME to program in Common Lisp (side projects, though). I make changes to .emacs or write an elisp function once in a while, usually to finesse something that I do frequently, but it's definitely not a hobby. It's a great tool, even before any customizations, IMO.
Earlier today I started up emacs in a C++ project after working exclusively in Rust, and I didn't have an lsp server for C++ installed. I did M-x lsp-mode and it prompted me (paraphrased): No language server for C++ installed, do you want me to go get one for you? Options are: clangd. Sure, said I, and it just went and installed it and off I went.
Granted, you'll also need company-mode and stuff, yes. And to get an IDE like experience... treemacs, projectile, etc. etc.
Yes, it's an acquired taste. But it's not like it's obsolete. It's better and more active than it's ever been. And I've been using Emacs (mostly casually) since 1992.
About projectile: Emacs ships with project.el and that does 90% of what projectile can do.
In particular, no, it did not do all the LSP stuff out of the box, and didn't do basic refactorings out of the box either. Maybe it does so for other languages? Or maybe they've fixed the UX? But I recall having to install at least two or three plugins. And along the way found some that fought with each other.
Maybe if I were a professional web developer, I would be able to modify vscode in the ways I feel it needs to be modified to support my personal style after a reasonable investment in learning vscode internals, but that is manifestly not actually the case.
BTW, I don't use and don't like org mode.
Many (most?) Emacs enthusiasts don't use it primarily for SW development. VSCode simply isn't an alternative for their needs.
Make two lists:
- List of things you can do in VSCode that you can't in Emacs
- List of things you can do in Emacs that you can't in VSCode
The latter list will be 10-100x longer.
- Read and reply to my emails?
- Manage TODOs across domains (so e.g. I can make a TODO that has a link to a specific email)?
- Use it as a Mastodon client (read and write toots, boost them, favorite them, etc)
- Scrape a web site (several pages), getting only the relevant content[1]
- Bulk rename/copy lots of files with a custom naming algorithm
- Chat on IRC
- Use it as a spreadsheet
- Do numerical integration with it
- Have a literate document with code in several languages that talk to one another
- Annotate PDFs
This is a tiny list. In fact, you can browse past Emacsconf talks to see how people use it.
[1] https://blog.nawaz.org/posts/2023/Mar/solving-a-scraping-pro...
> but "can your text editor/IDE do a bunch of not-text-editor-slash-IDE stuff?" is a weird gotcha.
It's not a weird gotcha when dismissing the tool. If you want to artificially narrow the comparison to "writing SW" (which is even narrower than text editing), then by all means - VSCode is the superior tool. But why stop there? The bulk of PC/laptop users use Notepad as their editor, and have no use for VSCode's capabilities. Shall we dismiss all the cool things in VSCode for it?
And sorry, what? Non-editor stuff? About half the items I listed are editor related.
> Sometimes you want to buy your dessert topping and floor wax in separate cans, y'know?
True, but wouldn't it be at least nice if you could buy both cans from the same store, using the same currency?
No one's arguing using only one tool. As I write this, I have both VSCode and Emacs windows open. Use the tool for its strengths. But blanket comparing VSCode with Emacs is silly - it's like comparing Excel with all of Linux. One is an application. The other is a platform. Excel is easily the best spreadsheet out there, but for many people, Linux is much more useful than Excel.
One, I wouldn't have conceded the crown to VSCode so easily as that. A fine-tuned Emacs config, with the requisite muscle memory and custom elisp, is a hot rod. I do use VSCode, and before that Sublime, but it was under protest, the details don't matter here but there were features I needed and no task budget for provisioning them in Emacs.
Second, why not stop there? I have a program for reading my email, it isn't VSCode, I'm fine with that. So telling me Emacs can read email is completely irrelevant to my use of VSCode. For most people, adding all of these features to the Emacs side of the balance backfires, because now Emacs has to be better than all the tools they use for that stuff, rather than just better at what VSCode does than VSCode is.
"Emacs does everything" is an aesthetic, and it has many decades of refinement, and people like it. That's fine.
> Most people don't need or want all the UNIX tools' capabilities. Does it make sense to compare the Windows command environment with the Linux one and say "Don't include all these capabilities in the analysis?"
This isn't at all what you're doing. It's more like if someone says "awk is fine for text munging, why would I use Perl" and your answer was that Perl has a web server.
There's such a thing as a like-for-like comparison. Emacs has org-mode, it has SLIME, it has paredit and parinfer. Those are all edges over VSCode, whereas checking email isn't. This conversation piqued my curiousity, and indeed, there's a plugin for that[0], a few actually, and yes, I'm sure Emacs does a better job, for some value of better. But I'll never know, because I don't intend to use either tool for that job.
All these things we're talking include editors in their separate applications. They just use the default OS editor widget using CUA bindings or whatever. Pulling them into emacs turns that on its head, and brings with it all the power (and weirdness) that comes with that.
It's not for everyone, but it's also not something that it's fair to make fun of or dismiss outright.
In the end, what the emacs nerds are doing is remaking the world of Lisp machines, but compromised and/or modified for the environments we have now. Not everyone digs that. I kind of do.
I took pains not to do that in either post I made.
> but compromised and/or modified for the environments we have now.
I would think that GNU Emacs is also compromised by its own design decisions, starting in 1984, when RMS rewrote Gosling Emacs.
I agree it is irrelevant to your use of VSCode. The comparison, though, was for VSCode with Emacs. Not "VSCode with Emacs for samatman's needs".
> For most people, adding all of these features to the Emacs side of the balance backfires, because now Emacs has to be better than all the tools they use for that stuff, rather than just better at what VSCode does than VSCode is.
It's illogical to say that Emacs has to be better than all those tools to use them. We're not enforcing a dichotomy. You can use both. You can use Gmail's web interface and Emacs mailing abilities. All you need is for one to have some capability that the other doesn't, as opposed to having every capability the other has.
Next: A large part of my point in this thread is that comparing VSCode to Emacs as a whole is in itself silly - one is a fairly specialized tool and the other is fairly generic. If you want to reduce the discussion to SW development, then fine. But people (not you) blanket saying VSCode is better (or worse) than Emacs is like saying Excel is better than Linux. I don't have any desire to convince someone to leave VSCode for Emacs. What for?
Next: Implicit in your comments is the notion that stuff like reading mails is an "extra" in Emacs. It's artificially categorizing. Reading email in Emacs is not an addon - it's part of Emacs's capabilities (although you may get better experiences than the default with addons). If reading/writing emails is considered "extras", then keep in mind so are things like syntax highlighting, debugging, compiling, etc. Emacs is a text editor, and all those features are addons - at the same level as reading mails.
As a VSCode user, some of these addons mean more to you, and you don't care about the others, but understand that lots of people do care about them. So many people out there use Emacs only for org mode and magit.
> This isn't at all what you're doing. It's more like if someone says "awk is fine for text munging, why would I use Perl" and your answer was that Perl has a web server.
Context matters. Understand that my list was in response to "What can Emacs do that VS Code can't?" If someone asked "What can Perl do that awk can't?" then mentioning CPAN and Web servers is totally appropriate. It's pointing out that if you learn Perl, it may benefit you far more than awk ever could. Whether it would or not depends on your goals, of course.
> There's such a thing as a like-for-like comparison.
Agreed, but it helps if the scope is stated clearly. More often it's "Why do you use Emacs when VSCode exists?" And then of course, I'll list all the things I do in Emacs that VSCode doesn't provide. If someone asks "Why do you shop at Walmart when you can shop at Whole Foods?" it's not a problem to respond with "Because I can buy electronics at Walmart." You wouldn't jump on him and say "Hey, you're not doing a like-for-like comparison!"
If emails is considered extra, then so are things like syntax highlighting, debugging, compiling, etc.
Yeah no. The first is email, the latter three are directly relevant to program editing.
I am repeatedly accused of this. Consider what I have written:
> then by all means - VSCode is the superior tool.
> No one's arguing using only one tool.
> As I write this, I have both VSCode and Emacs windows open.
> We're not enforcing a dichotomy. You can use both.
> I don't have any desire to convince someone to leave VSCode for Emacs. What for?
I certainly won't change any minds, because I'm not trying to.
> To nearly everyone reading this thread, the bulk of whom are under 35, emacs is just a programmer's editor, and will be judged on its program editing.
While I can agree they are the majority, this is a strange take. Do HN readers come to the site to reinforce their problematic views?
And do you think Emacs submissions often hit the front page because those upvoting view Emacs as "just a programmer's editor"? Quite a lot of these top voted submissions (the majority?) are not about programming.
> Yeah no. The first is email, the latter three are directly relevant to program editing.
You are welcome to whatever hierarchy you wish. From an objective architectural standpoint, all are extras on equal footing. I suppose perhaps some of these may have extended support in the C code, but otherwise they are just elisp libraries on top of the core.
In VSCode, I don't think there's anything like "place code in this file, run it at startup, and code within this file can be present/applicable everywhere". Maybe you could do something as a plugin, but that is a big lift compared to Emacs.
For example, think about doing a "Hello World".
In Emacs, you just open init.el and place `(message "Hello World!")`.
In VSCode, you have to follow a whole set up for an extension [0].
[0]: https://code.visualstudio.com/api/get-started/your-first-ext...
If you can do this in Visual Studio Code, it was not at all obvious how when I was looking. There's seemingly no way for you to add any code that executes in the editor's VM without literally restarting the process with your updated code in place. (Visual Studio suffers from a very similar problem.) 2 or 3 restarts is just the beginning! You'll need that many just to be sure you've got all the boilerplate in place.
https://code.visualstudio.com/api/get-started/your-first-ext...
That's the VS Code description on how to start writing extensions to VS Code. The first steps involve installing node.js so you can install another tool so you can generate scaffolding.
In emacs it would be:
Step 1: Open emacs
Step 2: Open a scratch buffer (q&d extensions, put in a .el file if you want to preserve it)
Step 3: Write some lisp code
Step 4: Evaluate the lisp code
Step 5: There is no step 5, use your extension
Caveats:
You have to learn programming to extend either of them so that's a common burden.
You have to learn lisp to extend emacs, but that's an easy thing to do.
You have to read the documentation to really get going with extension development, another common burden.
And on top of all that the actual core editor is, once you get your fingers wrapped around it, just... the best. It can do so many things that other editors just don't do, it's responsive and fast, the buffer metaphor it works with is great (so easy to have the same file open in multiple windows at different regions, it's beautiful) and I love the tiling system for its frames, etc. etc.
In 30 years, we'll still be using Emacs, but VSCode will have moved on.
Yes, you can use emacsclient, but that's a bit of a different thing and has its own disadvantages.
I'm pretty sure the authors of NeoVim heard wise advice like yours, but I'm happy they continued.
I dream about a day when programmers stop being fervent zealots about tools they use and instead try to find pros and cons of their tools and try to borrow good ideas from each other.
This 'Emacs vs. Vim vs. VSCode, etc. etc.' comes from poor understanding the core principles of each of these things.
Can we discuss these things without emotional attachment, or even forget for a minute that they are "editors". Instead of trying to find who's wining "the editor wars" (is it even a thing?), can we instead talk about the big ideas behind them?
- What makes Emacs so powerful for many, and at the same time so intolerable by many others? The big idea behind Emacs is Lisp. Without understanding the core principles of Lisp, and by "understanding" I mean truly experiencing the dynamic nature of it, its malleability, the structural editing, 'true REPL', 'code is data', etc., it is quite pointless to even start such a discourse.
Lisp is amazing. I firmly believe that every programmer should gain good familiarity with Lisp. I am forever indebted to my younger self for forcing myself to learn Emacs and Emacs Lisp and for discovering the beauty of it. Learning Lisp made me a better programmer. I'm not claiming to be a good programmer today, but I was much worse before I learned Lisp. Lisp helped me understand FP, composability, meta-programming, logic, recursion, lambda calculus, symbolic computation, generative testing, and even type theory. And I'm quite sure, many other programmers can share the same sentiment.
- Without understanding, I mean not just "understanding", but heartfelt use of it for many months and maybe even years of the fantastic, remarkable idea behind modality and mnemonics of Vim, it is quite impossible to explain what makes it irreplaceable for those who learned its power. And by the way, there's no such thing as vim-mode. No other editor or IDE truly was able to recreate that model, with one exception - Emacs. None of the IDEs - IntelliJ, VSCode, XCode, Android Studio, etc., can properly emulate Vim-navigation. Only Emacs does a better way of vimming. Pretty much every other IDE fails to replicate Vim. Unless it's Vim/Neovim, vim-mode in all of them is just that - an emulation. However, Evil mode in Emacs feels much more natural. Sometimes, you forget that it's an afterthought, an extension, and not a built-in functionality. And that's due to the power of Lisp. Also, these days, there's ton of interesting stuff getting build on top of Neovim, because now you can use Lua instead of vimscript. And with Fennel - a Lisp that compiles to Lua, one can build some really interesting extensions.
- Now, VSCode fancies the idea of being built on top of a web browser engine. Turns out, it ain't such a bad idea after all. Perhaps Vim and Emacs should also one day try to have their own, built-in web browsers. I mean truly built-in, so one can extend it and change it and build things on top of it.
I guess, it turns out there's no such thing as "editor wars". VSCode is more popular today because certain ideas behind it make it appealing for many people. For the same reason, certain ideas make Vim and Emacs more appealing for others.