I find it doesn't really matter what I'm interested in (computer-wise)---Emacs has me covered. It saves a huge amount of time to not have to relearn a new IDE each time I need to switch programming language. There is always more about Emacs to explore, but it is well invested time, as I know that Emacs is going to be around most likely for the rest of my life-time. The killer features for me are:
+ Org-mode
+ SLIME (Common Lisp IDE)
+ A Lisp as "extension" language (it isn't really extension---Emacs is fundamentally reprogrammable).
+ Really smooth integration of LaTeX, Dot and Tikz.
+ Rock, rock, rock solid no matter what I through at it.
Also, I find that for me, Emacs has ergonomically good key-bindings once I accepted that they are different, learned them properly and did the CAPS-Ctrl switch.
> Rock, rock, rock solid no matter what I through at it.
The main reason why I don't like Emacs is that it feels very fragile to me. The first time I tried to use Emacs seriously - granted, that was many years ago and probably things have improved - I wanted to change the font because it was using an old X11 pixel font. So I went to the settings, and accidentially deleted the combobox that allows you to choose the font. I tried to configure it with the command line or REPL or what it is called and managed to mess it up even further. Later, as I got more familiar, I regularly managed to get it into a state that required restarting. It seems in Emacs, everything is a mode and everything is an editor, and there is no separation between content and UI (except for things like the menu bar, which uses a different toolkit and is bolted on). I've learned to appriciate less configurable editors because there is less to screw up, and you have the same good experience on any PC without your special config.
I mean rock solid as in being able to edit buffers with very different contents of half a million characters, every day for decades without crashing. I wouldn't call what you describe fragile. It sounds more like a typical learning experience. You did something, Emacs obeyed and then you who didn't like what you just did :). There is a market for restricting choice, so you are clearly not alone!
But I don't think that the Emacs learning curve should be exaggerated, either. If you start it up and follow the instructions, you very quickly become productive. What gets people into trouble is usually when they expect Emacs to be like software X which they already know, so they don't read what's on the screen and kind of skip the introduction. And then they get frustrated when they find out that Emacs is Emacs. I'm not saying that's you, or that it is stupid, impatient etc. or whatever. I'm just saying that I've seen it quite a few times.
> I mean rock solid as in being able to edit buffers with very different contents of half a million characters, every day for decades without crashing.
There's nothing you can say to make me believe that.
Emacs is fragile. Any change, even the most simple change, to one's .emacs file can cause unexpected behavior. From fonts, to shell changes, etc. I have really wanted to like Emacs and get into it, but it's fragile from the very start.
> What gets people into trouble is usually when they expect Emacs to be like software X
This is the problem with Emacs. By default and by itself, it's nothing more than a glorified text editor. You have to update and configure it to get things to work as they should, but that's where the fragility comes in.
I've gone through this multiple times. Every time I try Emacs for some new language, I end up in configuration hell. The moment I switch to VSCode, while not perfect things just work, and I get to coding. Maybe I'll eventually bunker down in a hole and get Emacs to work as I'd expect, but that has not been accomplishable yet.
And I generally actually prefer using dedicated IDEs for languages. Otherwise, you're reliant on someone having implemented a usable Emacs mode.
> Emacs is fragile. Any change, even the most simple change, to one's .emacs file can cause unexpected behavior. From fonts, to shell changes, etc. I have really wanted to like Emacs and get into it, but it's fragile from the very start.
In Emacs you have control over absolutely everything so, of course, you can mess it up. The solution however is very simple, trivial even: just version your entire Emacs config in Git. Screw up something? Checkout the last known working version. There are people even going as far as versioning their entire user directory under Git (not just Emacs but everthing). At the OS level there are people using NixOS: where everything is reproducible.
You make it sound like it's not possible to have a deterministic system. It's not just possible: it's very easy (any dev should know how to use Git to revert back to a working Emacs config).
> And I generally actually prefer using dedicated IDEs for languages.
Then try the JetBrains tools. It's leaps and bounds above anything MS has to offer.
> In Emacs you have control over absolutely everything so, of course, you can mess it up.
That's not necessarily a feature in my opinion, and I don't like the framing that's it's me messing things up and not Emacs or packages. Look, Emacs is super powerful, but people always respond to things being difficult in Emacs with something along the lines of "just do this and then you get rainbows and the pot of gold". In reality, you're spending hours reading documentation and random forum posts on how to do the simple thing you want. Next thing you know you're having to basically write your own features into Emacs.
The thing I balk at is people acting like Emacs is just some under appreciated tool that just has a learning curve. No, it has a learning curve plus the difficulty of understanding its ad hoc design and the multitudes of packages, the way they're written and interact with Emacs, and the millions of ways various people like to do things. I just wish people were more honest regarding its complexity and the vast multitudes of ways that people use it in very individualized manners.
And yes, I have previously managed my .emacs file in GitHub. Not sure why you commented on a bunch of that. It's still not as easy as VSCode automatically syncing via my GitHub account or working automatically through SSH.
> Then try the JetBrains tools. It's leaps and bounds above anything MS has to offer.
That's actually what I was referring to. I use Dr. Racket for Racket, Visual Studio for F#, VSCode right now for Elixir, but I've considered trying out the Jetbrains stuff for Elixir, and if I was using Clojure, I'd definitely use IntelliJ with Cursive.
> The solution however is very simple, trivial even: just version your entire Emacs config in Git.
And all installed packages.
> You make it sound like it's not possible to have a deterministic system. It's not just possible: it's very easy
If you never update a package or install a new one. The more packages you have installed and use and the more (major and minor) modes you use (simultaneously), the higher the possibility.
Correct. As an undergraduate in the 90s when OOP got in vogue, I puzzled at
the bureacratic notion of data hiding and private variables. Emacs set me
straight on why those things are important.
Making changes to my .emacs never causes unexpected behavior. It does what I tell it to do.
Looking through my .emacs I really can't think of anything that would cause the chaotic behavior you describe. And the only revert I see in the last 10 years of git history is a key binding change that I decided I didn't like after all.
The only way I can see this happening is if you copy and paste random stuff from the internet without understanding it. But then what else could you expect.
I'm going to get downvoted to hell for this, but it's true.
Emacs is like dating a redhead. You're right: it is more fragile. It takes effort and dedication to figure out what you can do with it (more than you initially thought) and how to not upset it (more easily than you initially thought). But like the redhead, it's worth the effort.
>I wouldn't call what you describe fragile. It sounds more like a typical learning experience. You did something, Emacs obeyed and then you who didn't like what you just did
That's the definition of fragile.
The famous "You're holding it wrong", even sounds benign compared to "it's just a learning experience".
No, the definition of fragile is that if you use something in a wrong way, it breaks. But Emacs doesn't break. It obeys and keeps running.
With your reasoning, all software that gives you a choice, anything that can be configured, all programming languages etc. etc., become fragile, because as soon as someone says "I did this but I didn't like the result," your case has been proved. In other words, it is a circular definition.
Anyway, I didn't mean learning experience in a condescending way. The user I answered indicated himself that he was learning---and we all are, when it comes to Emacs.
I just tried changing the font through the menubar (Options -> Set Default Font) and wound up with a font which was unreadable, due to being only a couple of pixels high. I never use the menubar, so I'm insulated from that kind of issue (and I'm running bleeding-edge emacs, so it could be a transient bug), but I could see it being a showstopper for new users.
emacs users just live in another world entirely, this whole interaction I find typical of users who evangelize for emacs, and for some reason those users can never see the error of their thinking.
You sound like a zealot for thinking a settings menu breaking when trying to change a setting is acceptable.
Don't mean to come off like a zealot. To me, it sounds like the user accessed a show/hide-function in the graphical interface while using the mouse, and then didn't know how to bring it back (Control-Right Click or menu-bar-mode). The mistake and the ability to hide the menu-bar are both super common in any application and don't make Emacs fragile. Instructions for how to hide/un-hide stuff are in the manual.
I think people are just kidding themselves when they arrive at the conclusion that a program like Emacs---which is super mature, has a huge user base amongst very picky programmers and has survived in fierce competition for 45 years---is somehow fundamentally flawed, fragile etc. Of course it isn't. But it might not be your thing, and that's fine.
I use emacs daily and have done for 5+ years now. Even with that, It's undeniable that it makes some tragic choices that keep it from being popular in the modern day.
You see every few years a project to modernize emacs and get wider mindshare among developer community, and they always fail due to some stubborn choices due to stalwarts not admitting when they are wrong.
I have more faith in VSCode sticking around for the next 10 years than I do Emacs.
> I have more faith in VSCode sticking around for the next 10 years than I do Emacs.
I mean, almost everyone is confident about that too. And rightfully so because, VSCode actually has real corporate backing. People are being actually paid to develop it and sometimes plugins for it, so it would be a surprise if it didn't pan out. Nobody is getting paid to work on Emacs, or third party elisp libraries. It has always been individual hackers doing the bits that interests them. I don't want to come across like anybody owes Emacs anything. But I think in forums people sometimes take the reverse for granted, like Emacs owes anyone anything. Or that the people who actually bother to do voluntary work share the same vision of modernity as them, so it's a failure of some sort when that isn't exactly delivered.
> You see every few years a project to modernize emacs and get wider mindshare among developer community, and they always fail due to some stubborn choices due to stalwarts not admitting when they are wrong.
I think this is a mischaracterisation. Because, firstly you don't actually need the approval of the "stalwarts" to modernise it. Doom Emacs is making a name of its own just fine. The other thing is, Emacs is old. Most of the old vanguards aren't actively involved in Emacs development any more. Most of the "stalwarts" now weren't even around for most of the mistakes, why would you attribute things to vanity when it was not current stalwarts personally who were responsible for most of the design goals?
Browsing emacs-devel, it's clear that the real problem is acute lack of manpower. Only a fraction of Emacs users do bug reports, and then only a tiny fraction of them do actually get involved in fixing things. Which means the maintainers are always facing an uphill battle, who by the way don't have domain expertise or historical understanding of why things are the way they are, any more than you or I do, in many of the situations. Compared to that, VSCode is only a few years old, there are probably engineers who are familiar with the entire codebase, from conception to now.
That said, it has always been more or less like this. Emacs will be fine in its own way, because it will always attract certain sort of hackers. So sure, in terms of "mindshare" and "percentage of users", Emacs will keep free falling, specially now that software development itself has become way more pervasive. It might continue to get more out of touch with "modernity". However, as someone who has been in Emacs community for 7 years now, I believe the ecosystem is only getting more and more vibrant each year than the one before, in absolute terms (more mailing list or other forum activities, more landmark features, more new and high quality third party libraries etc.).
The vast majority of users get their emacs from the Linux distributions, who
in turn get it from the GNU people. To the extent they've monopolized that
distribution channel, the maintainers owe us something. They alone can revive
emacs's fortunes, or squander its good name by failing to keep with the times.
> To the extent they've monopolized that distribution channel, the maintainers owe us something. They alone can revive emacs's fortunes, or squander its good name by failing to keep with the times.
I don't even know how that makes any logical sense. The maintainers aren't what they are by virtue of nepotism. Rather they are only one who shows up, voluntarily. That doesn't mean they owe anyone shit, nor does it mean they are preventing others like you to show up and do what needs to be done. So no, if there is anyone who can "revive" Emacs' fortunes, it's people like you, that is if they bother to show up instead of complaining which is always easy.
I also don't get your obsession with "name". XEmacs was a fork, and for a while it was wildly popular. So if you have fundamental difference with emacs-devel, then go fork it? If your fork becomes worthy and solves many people's problems, then all linux distributions will package yours too.
The entire Guile Emacs thing was a product of a GSoC project, the moment it ended so did the project. None volunteered to take up the mantle, even though to this day people lament in forums about how it never became a thing. Turns out that solutions don't magically manifest without people putting the work, what a surprise. But I suppose this is to be expected, when people become too spoiled by other people's labour.
It's OSS, people can and have forked it before, if the present (primary) maintainers aren't doing what people want then they can do it themselves. In the meantime, quite a few people are using emacs as it is and it is getting updates that people seem to care about (like native compilation of elisp).
They don't own it in any meaningful sense. They do not prevent others from distributing variations and forks via those same channels. It's not like Apple or MS who would sue someone for releasing "Xcode-but-not" or "Visual Studio but not". That's the beauty of OSS. Until you pay them or your desires otherwise align with theirs they don't have to do anything for you, but you aren't prevented from doing it yourself.
Okay, I'll make sure Ubuntu's next release puts my fork of emacs in /usr/bin instead of Gnu's. If you're still not understanding this, you might read Nudge by Thaler and Sunstein.
You used the term "monopoly", which is absurd. It's FOSS for crying out loud. Literally fork it, that's what XEmacs did (which has fallen by the wayside). Sure, you can't get Ubuntu to publish your emacs alternative as if it were GNU Emacs. Boo fucking hoo. The Ubuntu maintainers have too much sense to be talked into doing stupid things by you. But if you build it and develop a community, you can get it published through their package systems just like all the other software out there. You have to do some work to get there, but so did everyone else who has a package in all the Linux distro package management systems.
If you believe that there is a fundamental flaw in the GNU Emacs maintainership and you cannot join them to influence it yourself and you care enough, fork it. Build your own community. Give it its own name (Valmer Emacs, vemacs for short) and get on with it.
> emacs users just live in another world entirely, this whole interaction I find typical of users who evangelize for emacs
It's not that emacs users "live in another world entirely", it's that some things a very difficult to explain to folks who don't have first-hand experience of those things. Try describing what minus 20 degrees Celsius feels like to someone who's spent their entire life in Florida, or Brazil. You can't really, it has to be experienced to be understood.
It's no different with emacs. Emacs doesn't really make any sense until you use it for a while, then all of sudden you "get it" and don't want to use anything else.
> You can't really, it has to be experienced to be understood.
No, I'm pretty sure everyone knows what fragile software feels like.
Disclaimer: I've been using fragile emacs as long as most HN users have been alive.
It wasn't a "defense", so much as a statement of fact. I enjoy using emacs, but I don't go around trying to get the whole world to use it. I know that emacs occupies a very specific niche and is not for everyone. I don't spend a lot of time worrying about how much market share emacs has, it has enough to keep marching on, and that's about the extent of my concern.
But the point remains. You can't really understand emacs (or a lot of other things for that matter) in the abstract, you have to use it. So use it or don't, but you can't really offer meaningful criticism without have it used it a fair amount. There are plenty of warts on emacs, any emacs veteran (which I'm certainly not) will freely acknowledge that. But it does seem that most criticisms of emacs come from folks who haven't used it much.
> With your reasoning, all software that gives you a choice, anything that can be configured, all programming languages etc. etc., become fragile, because as soon as someone says "I did this but I didn't like the result," your case has been proved
That's not at all true. It's called "validation" and "error handling". What kind of farce are you getting at? You unironically think a text editor that lets you break its settings panel by trying to use the settings panel normally isn't fragile?
I am quite annoyed at downvotes that don't challenge my assertion. Any UI which allows you to directly compromise the environment to the point of requiring a fresh install is the very definition of fragile. I understand that HN is strongly biased against UI development and undervalues the domain, believing instead that tools only accessible to experts are fine, but I think this is an extremely user-hostile POV and to advocate for tools to have this level of footgun built into A FONT MENU is comically sloppy. I can only imagine the comments if someone did this in JS, yet because it's emacs? No comments, only downvotes
I'm on the fence about this one, because tools for consumers are a bit different than tools for technologists. Yes UX matters for us as well, but there's a commonly accepted belief that initial-difficulty-of-use is worth the eventual efficiency gains that the tool offers. I've never gotten into Emacs but I believe devs when they say it makes them hyper-productive.
> So I went to the settings, and accidentially deleted the combobox that allows you to choose the font.
I'm genuinely curious how you did this, and how you did it in a way that was permanent. The customization screens are read-only by default (except for those boxes you type text in to specify the customization) and they're programmatically generated, not fixed.
It seems a bit disingenuous to say "emacs can do everything" citing org, slime, and auctex, which are probably the three highest-quality extensions out there (maybe throw in magit too). In my experience this level of polish is not consistent, e.g. python or java support is much less robust. Emacs is indeed great for many things, but not everything.
Java support is, unfortunately, iffy in every editor that isn't made by JetBrains.
I've recently got Python working well. It can be done. The deeper problem - and this is admittedly ubiquitous in emacs - is that the defaults are awful, and there is not even good discoverable official documentation about what configuration you should use because everyone's just a wee bit too content to allow, "We have a very welcoming community on IRC!" to stand in for a proper new user experience.
Hi. I am absolutely a dyed-in-the-wool JetBrains "fanboi", but I need to counter this statement: <<Java support is, unfortunately, iffy in every editor that isn't made by JetBrains.>>
Both Eclipse and NetBeans are outstanding (and free) Java IDEs. To be clear: I write this as someone who does not make extensive use of plug-ins with IntelliJ. I am almost exclusively using the default plug-ins provided by JetBrains. For many, many years, NetBeans was (enviably) considered the Gold Standard for Java Swing GUI design that was drag-and-drop. I knew developers who used NetBeans only for GUI design, then IntelliJ or Eclipse for other work!
Finallly, I have never used Visual Studio Code, but I also assume -- at this point -- that it is very good with Java. The speed at which their community has grown is simply breathtaking.
I am interested to hear from other people if this agree or disagree with me.
>Finallly, I have never used Visual Studio Code, but I also assume -- at this point -- that it is very good with Java. The speed at which their community has grown is simply breathtaking.
Unfortunately, that's not the case. I tried using VSCode with its Java development extension pack last week and I found that it was nowhere near as polished as, for example, its Python or Typescript extensions, both of which are gold standard. I ended up switching back to IntelliJ.
This is my experience as well, VSCode has been excellent for TypeScript, but it is lacking a lot when it comes to Java. I'm much happier with Eclipse. I'm sure IntelliJ is great too but Eclipse works fine for me and I've never felt the need to drop it.
Basically: if poetry project file exists in project root, get the path for the active venv with poetry and activate with the emacs pyvenv package. This adds a little jank when switching projects I haven't looked into ironing out yet but it is functional.
I use elpy regularly for python development. Handles virtualenvs really well, makes it super easy to run one or all test cases. Good support for linting and reformatting (black).
I should note that I don't work on large codebases. My codebases have ~20 files and <20,000 lines of code total. I know some folks prefer LSP and that might be the reason.
I spend most of my time in Emacs (Clojure/Script), but if I'm writing JavaScript then VS Code works so much better. Maybe I haven't spent enough time tweaking Emacs for JS?
> Rock, rock, rock solid no matter what I through at it.
That's actually not how I would describe Emacs.
Not for Common Lisp either, Sly (and before that Slime) always had some glitches where I had to restart them or Emacs.
Well, to each their own. I never have to restart Emacs. The only time I restart SLIME is when I do something I shouldn't, like redefine a struct or something. I'm sure I could avoid restarting SLIME, too---I just never bothered to learn if there is a way.
BTW, all software that changes will have a bug from time to time, but Emacs and things related to Common Lisp are like at the very bottom of the trouble-frequency charts. I can't think of any software that I use regularly that gives me fewer problems. For the record I never encountered a bug in either (which doesn't mean they don't exist).
The problem with Emacs' configuration file is that it's processed in an additive way. Removing options and reloading the config does absolutely nothing. So in certain situations a restart is just inevitable.
But aside from that Emacs, like most programs, has a UX philosophy that I can't stand. And while Emacs lets me change that I don't want to manually redefine things for every single filetype and mode I'm using. Vim just does it right unless I make the mistake of writing JS in HTML files.
But you can always revert a configuration choice you made without restarting Emacs. Either use the built in configuration interface, or evaluate a form with the change. For example, if you set something to t you can reset it to nil and just C-x-e that form.
> Rock, rock, rock solid no matter what I through at it.
This is definitely not my experience. I regularly see emacs lock up indefinitely when asked to handle large buffers, especially when also using TRAMP. Even when it doesn't lock up indefinitely, it can easily stall for minutes(!) when doing something like moving point to the end of a large minified JS file (C-E).
There are many reasons to love Emacs, and I use it as my main development OS almost, but stability and performance are not among those reasons.
Note: mostly used it in console mode on Linux (Ubuntu WSL 2).
Well, I guess we have different experiences then. That kind of thing hasn't happened to me in 25 years. Not once.
The OS could matter, I guess. I didn't even think about that. I used Debian Stable and have been since the last century. Always a version or two behind, at least, so I guess bugs could be resolved before I get a chance to encounter them.
I have experienced the same things but even so I would classify it as fairly rock solid overall. Under certain circumstances a rock can split. I see far more fragile, and unpredictable behaviour in other environments.
It must be said that large file handling is an area that could do with some improvement - vlf-mode is okay as a workaround but it would be nice if I could deal with a large file in much the same way as a regular sized files. Few environments will provide this either though.
> Few environments will provide this either though.
I used vim for ~12 years and then emacs for ~12 years, and this emacs has never been able to handle large files well. vim meanwhile has zero trouble with files of any size that I've ever tried.
"Vim can do it" doesn't counter you saying "few environments" though. I haven't needed to look much farther than vim/emacs.
I was thinking more along the lines of eclipse or IntelliJ … yes of course vi/m can do it and that would be my go to for quick edits on the console, the kind of thing that typically lends itself to large files funnily enough.
Now that I’m talking about it I do remember a couple of times where vi (rather than vim) choked on some very very large files but she always got there.
+ Org-mode + SLIME (Common Lisp IDE) + A Lisp as "extension" language (it isn't really extension---Emacs is fundamentally reprogrammable). + Really smooth integration of LaTeX, Dot and Tikz. + Rock, rock, rock solid no matter what I through at it.
Also, I find that for me, Emacs has ergonomically good key-bindings once I accepted that they are different, learned them properly and did the CAPS-Ctrl switch.