I think I fell in love with emacs when I realized that individual key presses could be scripted. Or possibly when I wrapped my head around macro injection. Hard to say, this thing grew on me from being an absolute space alien of an architecture to the first tool in the toolbox I reach for if I've got a new project to tackle.
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).
Yes the day you find out that in GNU Emacs, the "u" key is actually bound to (self-insert-command) and thus can instead be made to do anything ... well,it's quite a day.
> I happened to learn emacs first and would be repeating a lot of labor to go as deep on vi.
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..
Is this based on Hemlock, or was it written from scratch?
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".
When building it, choose “make sdl2” to get the graphical UI. I also build the text UI, but the sdl2 UI is more fun and is very responsive. I didn’t see any ability to draw graphs in the window.
I can understand wanting to restrict use of something a person created using a restrictive licence. I can’t understand being sad about someone else not restricting what they created. To me it looks like someone being sad after seeing someone else giving out free ice cream, even though the person being sad didn’t contribute to making the ice cream.
My view on the GPL is that it's freedom-preserving, like how a law forbidding the enslavement of people is freedom-preserving, even though it technically restricts a freedom. That's why I look more favourably on GPL software than software with a so-called 'permissive' license.
This and similar arguments in this thread work on the same logic that frames software piracy as theft. It’s the fallacy of treating software as a tangible thing that, when copied, is taken away from someone and altered irreversibly.
That's ridiculous. The GPL explicitly allows people to make copies.
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.
> What many free software advocates actually want is a world without copyright on 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.
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.
So you’re fine with software provided as opaque binaries without source code or only as SaaS? Because without copyright you’re going to get more of that and no licence is going to stop that.
No, of course I'm not ok with that! But trying to get rid of copyright for software and make access to source code a right is a huge task. That's why the GPL is a pragmatic solution. The GPL is something we can use today to build a foundation of free software and make the idea of software freedom normal and expected. This smooths the way towards a future where we don't need the GPL, but we've got a long way to go yet.
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.
And even the threat of that (and *GPL’s viral nature) makes it INCREDIBLY unlikely legal teams allow employees to even use binaries of the code on their workstations. Of course nothing is actually stopping them, and it would be hard to prove it if they did, but there is at least some semblance of a threat.
MIT and similar are simply roundabout ways to make it public domain.
I care a great deal for the GPL, but I'd be fine with copyright if it wasn't so stupidly long. The reason I care about the GPL is my belief in an informed public. As far as I'm concerned, withholding vital information (like a list of ingredients or source code) from the public should be a criminal offence.
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').
For those confused by the dangling modifier, he means the combined act of cutting the trees and selling the wood is restrictive. Also, a terrible analogy since trees are an exhaustible resource within a meaningful time range.
> ...even though the person being sad didn’t contribute to making the ice cream.
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 poster I replied to complained about someone choosing MIT over GPL, not a proprietary licence over GPL. Noone is blocked from contributing for legal reasons. Quite the opposite.
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.
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.
If you want to argue that licenses are picked randomly then OK. But in that case, people should pick the GPL; it is a better license for preserving the freedom of software users than the MIT license.
> ... 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.
> It is setting up a situation where users will not be free.
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.
But it sounds like we have found agreement on the point that the MIT license is setting up an option B, where a person is blocked from contributing for legal reasons?
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.
The MIT license is explicitly designed to be compatible with building proprietary software. The key point of difference from the GPL is that you can use MIT code to create proprietary software.
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 can't understand being sad about someone not restricting what they created
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.
Yeah. I can get this angle. This is why we don’t have small independent companies making C and C++ compilers today. Only BigCorps which fund this development with money made from less honourable business.
I call these personality types free software socialists, and free software communists. The free software socialists are my friends. The free software communists are not.
I suspect that if someone is in a position where they are compelled to purchase and use the proprietary version and not the free (and available) version, they already lack most software freedoms. Probably several other, more important, freedoms as well.
Although I agree, notice that the only act the GPL compels someone to do is to hand over the source code with the program.
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.
MIT doesn’t give anyone the ability to restrict the freedom of others. When you fork a project and use a difference licence for it, the original project remains under MIT.
I tried out Lem a couple times, and I was impressed, but couldn't see myself moving to it. What was impressive is how starting it up just.. worked... with LSP type stuff... I was editing Rust and that all functioned. Not as featureful as my Emacs setup, but further along than I expected. And the keybindings were mostly familiar.
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.
After reading this article this morning I went down a very fun rabbit hole today: removed my SBCL installation, installed Roswell to install SBCL again, etc.
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.
Really? I find that the one really good design decision that survived in GNU emacs over all these years is that it does not have dialog windows. But it seems that that's pretty much what Lem does, at least when you find a file?!
Technically GNU Emacs does have dialog windows (at least the GTK version): if you click File in the menu bar, followed by 'Visit New File...' it opens the GTK file picker.
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.
I'm assuming that is something you could get rid of, if you want. It was more the popping over to the repl of the editor that I found fun to watch. And the fact that it was working.
The flake is unfortunately stuck on an old version (v2.0.0), since they changed how it's built with v2.1.0 and I haven't gotten around to fixing the flake, I'll try to see if I can get an update for it soon.
I like the idea of a more modern Emacs that uses the full power of Common Lisp a lot, but I worry I'd miss a lot of features. Does Lem have org mode, a good LSP system, something like projectile, and the ability to display images and GUI buttons and such? And most importantly, does it have an evil mode with doom/spacemacs style leader key support?
Take a look at the GitHub readme[1]: “Lem supports other programming languages thanks to its built-in LSP client. You can choose between an Emacs and a Vim 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.
Thank you! I actually found my way to its website and then downloaded, compiled, and briefly tried it after I posted this comment and discovered things for myself. It looks like it doesn't support a leader key so that's a pretty big blocker to me using it for even basic editing, but you're correct the bigger reason I won't use it is because it doesn't have the truly incredible emacs ecosystem.
Yes, I mean, I use all a lot of those things (haven't caught the org-mode bug tho, it's too incompatible with my attention-deficit...) but to be frank a lot of the stuff I jam into emacs (vertico, treemacs, projectile, all-the-icons etc) is in fact to get around UX issues with stock emacs.
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.
Completely off topic but this website is how it should be done. No JavaScript enabled and I can play the videos and see the text and images. Well done.
Sacha Chua does God's work for the Emacs community with building the Emacsconf infrastructure and her Emacs newsletter. See her blog on how she set up auto captioning:
Yup. I’ve downloaded the Webm file and iOS doesn’t know what to do with it, which is odd, since Apple allegedly added support for Webm in iOS 15. I’m on iOS 17.
> which is odd, since Apple allegedly added support for Webm in iOS 15. I’m on iOS 17.
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.
I don't know the reason in your case, but for a few weeks ending today, I wouldn't have been able to either, due to a long-standing issue with Opera and libffmpeg.so.
Today Opera updated itself and everything now works fine, at least until the problem recurs. Maybe you have a similar problem?
In the mid-1980s there was a commercial Emacs workalike (on floppy disks) for the IBM PC, called The Final Word, later acquired by Borland and renamed Sprint. For printing, it featured a workalike of Scribe, an early text markup language and precursor to HTML by Brian Reid. In law school I'd used a TOPS-20 Emacs and Scribe for law-review work, so later I bought The Final Word and an early HP LaserJet printer to produce camera-ready copy for my first book. Good times (sort of).
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.
Yea sorry for the misinformation. I'd read an earlier version of the Emacs wikipedia page that made it seem like Gosling Emacs was the original. The page is clearer now.
It's weird to be building an Emacs clone nowadays. It's fairly clear that Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top. That's not to say either Vim or Emacs are dead or will disappear, but building a clone of a niche editor is risking dooming the project to being a niche within a niche.
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.
Speaking from personal experience, I moved from VSCode to Doom Emacs a year ago, and the on-ramp wasn't nearly long or as tough as I thought. The defaults are good, and anything else that I customized I actually just used ChatGPT/GPT-4 to generate it. It took about a month to get used to the new setup. With LSP/Magit, it feels like I'm not missing out on much from what VSCode offered, and then whenever I want to personalize it, I can. For a creative person (which I'd argue most developers are, kind of by definition), it's fun.
I've been using Emacs for roughly three decades; it's my favourite editor. And for sure, LSP has been an absolute game changer.
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_.
>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.
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.
"savvy enough" for emacs these days for lsp is literally "M-x package-install lsp-mode"
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.
I was gonna mention that installing lsp-mode is as easy as clicking 'Options->Manage Emacs Packages', scrolling down to lsp-mode, clicking it, and clicking 'Install', however it turns out lsp-mode isn't in GNU or NonGNU Elpa, so it requires setting up MELPA first. So unfortunately it isn't entirely tech journalist friendly.
I'm sorry maybe this has improved in the two years since I tried but the last time I tried to set up VSCode to even approach the capabilities of CLion (the tool I used most at the time) it required a whole bunch of configuration, and stuff that felt more brittle and confusing than the emacs setup I have now.
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.
I have never used VSCode for C/C++, only Emacs and Visual Studio, so I can't comment on how it compares to CLion. VSCode and C#, however, is something I prefer to Visual Studio or even Rider.
> Emacs is for people who want to make editor customization a _hobby_.
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.
I've also been using Emacs for 3 decades. Although I could probably be happy with vscode for coding, neither vscode nor any other app I am aware of is a satisfactory substitute for Emacs as a personal information manager (PIM) because neither vscode nor any other app can be modified easily enough. (Apparently, I care whether my PIM supports my personal way of working more than I care whether my code editor or IDE does.)
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.
BRIEF by UnderWare! I loved that editor. I particularly liked the “go to this line number, but use the line number before unsaved edits”. This let you compile a file, get the error log, then start making edits; but the line numbers in the error log were still useful.
Atom is not around. Not 100 percent sure that VSCode will be around. (But I also don’t think that this should hold anyone back who finds VSCode to fit their needs best. There’ll be something else that will take its place.)
My impression is that all of those are fads, we jsut haven't seen VS Code fade way yet, like the others have. I've used Emacs throughout all of those fads, seems easier than switching editors every few years.
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.
I think it's fair to say that most people don't need, or even want, their IDE/text editor to do a bunch of stuff that can be done with other programs. I know Emacs people like it (I was, at one time, an Emacs person), and that's great, but "can your text editor/IDE do a bunch of not-text-editor-slash-IDE stuff?" is a weird gotcha. Sometimes you want to buy your dessert topping and floor wax in separate cans, y'know?
Emacs is the can class, not two can instances. The power comes from a single can interface, and leveraging one's can-fu across multiple tasks. Also, everyone enjoys some foot cheese in their whipped cream.
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?"
> 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.
> 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?
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.
The reason some people, including myself, like to do things like email or irc or whatever inside emacs is because we got hooked on the powerful text and buffer management facilities in emacs, and want them everywhere, and consistently.
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.
> 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.
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!"
While I, an inveterate emacs user, largely agree, you're not going to
change any minds when the debate topic is "Vim and emacs both lost to
vscode in the editor wars." 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.
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.
I don't think there's anything that's technically not-doable in VS Code that emacs can do. For me, it's more about ease of use that differentiates the two. Specifically around extensions.
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.
Apologies if this is do-able in VSCode, but for me the killer feature of Emacs is that configuration is literally just running code.
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].
This is the best thing about it for me as well. You can experiment with M-: or the scratch buffer to figure out what exact bit of elisp needs to be invoked; then use defun in the scratch buffer to make an interactive function of it; then use M-x or a keyboard macro to test it repeatedly while you're fiddling around; then assign a shortcut and test that out too. Once you're done, you've got everything in the scratch buffer and/or M-: history to paste into your init.el. Worst case, you'll mess up your startup file and need maybe 2 or 3 restarts total to ensure that you've captured everything correctly.
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.
Check out org mode (very complex and advanced task management / todo list system, calendar, etc), org roam (basically all the features of Obsidian), the ability to act as an email client, having a cross platform system shell independent shell (in elisp), and of course just general emacs architecture things like the ability to hot reload and replace and debug and inspect and get docs on and add to and modify every part of the editor
Software definitely doesn't have to be popular to be useful. Not being extremely popular comes with advantages as well. Nevertheless, Emacs is probably more popular than a lot software shared on Hacker News.
If someone is interested in lisp, you can assume they aren't driven by mass market popularity. Why on earth would want to go up against MS on their turf???
emacs and vim were niche way before VScode was around. The goal was never market dominance. It's not a market. It's a tool. With users. And these users are also active contributors to their own ecosystem.
> Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top
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.
My Emacs is full of extra bits and pieces, and it cold starts on a Pinebook Pro in 6 seconds. That said, I still run an Emacs daemon and use Emacs clients, which start up in milliseconds.
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).