IRC and Emacs all the things
200ok.ch
200ok.ch
Once I learned Emacs to the sufficient level, I felt that. Today, I can't even imagine typing any text in anything else but Emacs. Having all the tools you need at your disposal - spellchecking, thesaurus, dictionary, word lookup, translation, etc., feels extremely empowering.
My work machine is a Mac. I have written this¹, mainly to integrate with Emacs. Whenever I need to type anything longer than four words, in any program, I use that. The idea is simple - to copy existing text, call emacsclient, it invokes a function that opens a buffer and pastes the text into it. Then you edit the text in Emacs, press dedicated key-sequence - it grabs the text, switches back to the program, pastes the text back in there. It works surprisingly well. I can for example, open Browser Dev Tools; invoke Emacs; switch to js-mode, have all the bells and whistles: syntax-highlighting, autocomplete, etc.; write some javascript; finish editing and it would paste the code back into the Dev Tools console.
Sometimes I use Linux with EXWM. When I first discovered it, I got very excited. Not because now I could manage all windows through Emacs, but mostly because EXWM can "translate" and "simulate" the keys. So, for example, you can use same key-sequences that you use on Mac, but they'd translate into Linux native keys. There's no "context switching", you don't need to re-adapt to the keys all the time. It took me a few hours to learn EXWM and configure it, next day I wrote exwm-edit² Emacs package.
Being able to write any kind of text in your favorite editor is truly liberating. I highly recommend trying. Be warned though - it's impossible to live without that later. The only reason I don't much use Windows these days - because I haven't yet figured out the way of doing this in Windows. Someday I will.
---
C-a/C-e = Control-a/Control-e: move to beginning/end of line. In vim, normal mode 0/$.
It feels silly saying this about a piece of time-tested software that many people love, but as someone who believes in the idea of Emacs, in my opinion the reality of Emacs is that it just doesn't work very well. It's slow, it's clunky, it gets in your way at every opportunity, it's documented in a very puzzling style, the add-on packages often interfere with each other in inscrutable ways, and the user experience is on the whole, terrible.
At least that's how I felt coming back to Emacs after using modern IDEs the past few years.
You shouldn't think of Emacs as an editor; it's a text processing system. In other words it supports lots of workflows of which IDE is only one.
I also use it as a knowledge management system (org-brain) and task tracker (org-mode). It helps me manage my days because it hooks into google calendar. I manage my bugs via a JIRA integration, read my mail through it and now I'm gonna check out the IM mode :)
I feel this term might need to be officially dead and buried. If something as customizable as emacs is deemed opinionated what does this even mean? For chrissakes there are people that consider emacs to be a better vi implementation than vim.
isearch-forward turns on a minor mode that has it's own keymap
a snippet from isearch.el:
(defvar isearch-mode-map
...
;; Several non-printing chars change the searching behavior.
(define-key map "\C-s" 'isearch-repeat-forward)
(define-key map "\C-r" 'isearch-repeat-backward)
(global-set-key [f12] 'isearch-forward)
(define-key isearch-mode-map [f12] 'isearch-repeat-forward)
I don't see what is the problem here
It shouldn't be surprising, seeing as Spacemacs development ground to a complete halt (no new releases) something like two years ago.
Spacemacs is a neat demo of what is possible with Emacs but it adds a TON of complexity and bloat. I found it much harder to troubleshoot and it didn't keep up with the rest of the ecosystem, and it's the rest of the ecosystem (and Emacs Lisp) that make Emacs so special.
The hardest part of Emacs is to learn what Emacs can do, what it offers. And many gems are hidden under so many layers, that people may not even know about them after decades of using Emacs every single day.
And Spacemacs can be fast and predictable. But you need to know where and how to tweak it to make it so. For the past few years of me using Spacemacs, I had maybe three of four incidents when after updating things, something would break in a way that it would take me longer than ten minutes to find a workaround.
Nah, for me the hardest part is finding out about all the things it doesn't do. Unless you code it. Maybe you find some half-arsed packages, but they might just make you more frustrated.
For example, I still haven't found a way to do vim-like completion. I still haven't got a good cscope interface that doesn't crap all over my windows (a common problem for many things in emacs, not just xcscope). I still haven't found a way to make my custom keybindings just work everywhere; every so often I happen to end up with focus in a window where, for example, my normal window navigation bindings don't work and I'd have to go out of my way to fix it.
The easiest way to do this is to use `bind-keys' (specifically, the one with an asterisk after it, which HN markup won't seem to let me use without creating italics instead), which creates a global map for your personal key bindings that override other bindings (so, use it thoughtfully, and remember that `describe-personal-keybindings' will list them). It's best used in the `use-package' macro, like:
(use-package ace-jump-mode
:bind* ("C-." . ace-jump-mode))My dream editor would combine the flexibility of emacs w/ the speed and quality of sublime.
it's true in the sense that it's true for almost anything once you start to add a plugin or two or add personal customizations.
The only thing for me that is actually consistently, superfast is terminal vim without any plugins. Which is too barebones for my daily use.
In a realistic, daily working environment with all my stuff loaded emacs is clunky, but not necessarily slow. It's honestly still pretty responsive.
Three examples:
I use the windowed Mac version most of the time, and touchpad scrolling is so slow that it's basically not a reasonable way to get around a file. Compare to Sublime, where it's silky smooth, and you can get an almost physical feeling of where things are, which makes zipping around using scrolling very effective.
I run my shell inside emacs (which is super nice -- how do people survive not having easy immediate access to command output)? But if a command is going to generate a lot of output (e.g., if I have the misfortune to be running mvn), I'll need to either drop back to terminal or redirect the output to a file, or be content with my command slowing down 100x to wait for emacs to render the output.
Try opening a file that happens to contain a very long line (this happens sometimes w/ generated code, or json data, or ...). Emacs will basically freeze, due to some N^2 in line length algorithm somewhere.
It's no easy task, but I do think it's possible to make something w/ the near-infinite, excellent flexibility of emacs, while also hitting a much higher speed and quality bar.
But... I wonder how much my preference is conditioned by years of Emacs and its subpar scrolling? My preference for pagination+search extends to other software; to browsers, for example (spacebar or ctrl+f over mouse-wheel), but is that just a habit I got from my constant Emacs usage (I typed this comment in Emacs)?
In emacs, I mostly navigate around by searching, or sometimes by outlining (hide all lines that aren't a definition, move to definition, unhide).
But I do remember before I became an emacs addict, and there was something very nice about having a physical sense of your file layout. If you have that sense, scrolling can an efficient way to navigate a file (well, up to a certain size, anyway).
And I think there's something valuable in the almost subconscious feeling for the layout of the file you get as you scroll thru it.
When I'm mostly in emacs, my sense of what a file "is" is much hazier, because I'm just warping from one place to another.
(On the other hand, maybe the entire concept of a file as a linear progression is antiquated for source code...)
And these are not 400 "dead-weight," useless packages. These are real programs that very often tightly integrate with each other. Some of them like Magit and Org-mode are quite serious products by themselves.
Sure, there are decades-old issues in Emacs, and they are slowly, steadily being worked on. The problem with long lines is getting fixed. JSON performance got improved with jansson. Elisp native - some people reported a 300% speed boost. Rendering improvements with Cairo - no longer experimental; Native line numbers are in the stable version of Emacs; People today discussing using Tree-sitter for parsing, which would significantly improve syntax-highlighting. And many other things are slowly being improved.
Things move slowly in the Emacs world. We have many smart people, but we don't have enough of them to contribute and move things fast.
But I'm not sure it will ever be what I would consider high-quality!
I think it's just the nature of a huge system implemented (mostly) in a dynamically typed, dynamically scoped (!) (though, happily, more and more less and less) language to be partly broken all of the time.
And, to be fair, most of the bugginess is not emacs per-se, but in the various packages and their interactions -- but what is emacs, really, other than a platform to run the packages?
So here's some random problems I have (I have a long list, and occasionally I try to fix one; the list is growing):
- After I run a python shell for a while, bash shells stop asynchronously showing command output; the shell just hangs until the command completes.
- There's an awesome mode iedit that lets you edit all instances of a symbol. Sometimes, for certain sequences of characters, instead of correctly performing the edit, it inserts gibberish.
- There's an awesome mode grep-ed that let's you edit grep(†) results inline; very convenient. Except for when it very rarely, randomly decides to garbles the files.
(† Or even better ripgrep -- random shout out to truly fantastic piece of software!)
- The afore-mentioned iedit mode doesn't work w/ the delete-horizontal-space editing command. (All other commands, yes, just not that one, for some reason.)
- There is a mode dumb-jump that jumps to symbols. There is an emacs feature to soft-wrap lines. Dump-jump doesn't work when jumping to a symbol that's on a wrapped line.
- To work around a rare but tricky race condition, emacs shell mode at some point added a built-in 1-second startup delay. I lived w/ annoyingly slow shell starts for months before I finally tracked it down, only to find out it was on-purpose terrible kludge!
- The soft-line wrapping mode (visual-line-mode) goes crazy if the line gets really long.
&c &c &c.
So while I spend most my time in emacs and have great affection for it, I definitely don't feel like it's a high-quality experience. I'm constantly running into little bugs.
To be fair, most of my arguments are with 3rd-party packages and their interactions, not emacs per-se. But emacs w/o 3rd party packages would be like a non-fat decaf latte: what's the point?
(P.S. Very excited about the possibility of fixed long lines & tree-sitting parsers!)
To be clear, Elisp has had lexical-binding for about 8 years now.
> After I run a python shell for a while, bash shells stop asynchronously showing command output; the shell just hangs until the command completes.
That's very strange, indeed. See if you can reproduce with emacs -q.
> There's an awesome mode iedit that lets you edit all instances of a symbol. Sometimes, for certain sequences of characters, instead of correctly performing the edit, it inserts gibberish.
iedit is great. I've never seen it insert gibberish or misbehave in any way.
> There's an awesome mode grep-ed that let's you edit grep(†) results inline; very convenient. Except for when it very rarely, randomly decides to garbles the files.
Haven't heard of grep-ed. Maybe you're thinking of wgrep? See also occur, which can also perform edits. In fact, there are probably at least 5-10 packages which implement such functionality, some of which are built-in.
> The afore-mentioned iedit mode doesn't work w/ the delete-horizontal-space editing command. (All other commands, yes, just not that one, for some reason.)
It would be helpful to report that issue so it could be fixed.
> There is a mode dumb-jump that jumps to symbols. There is an emacs feature to soft-wrap lines. Dump-jump doesn't work when jumping to a symbol that's on a wrapped line.
That's unlikely. If that ever were the case, it's probably fixed by now, because dumb-jump is under active development, very popular, and widely recommended, and that would be a very basic problem. Besides, I can't imagine how being on a wrapped line would affect it, because Emacs commands that read from the buffer aren't affected by visual-line-mode.
> To work around a rare but tricky race condition, emacs shell mode at some point added a built-in 1-second startup delay. I lived w/ annoyingly slow shell starts for months before I finally tracked it down, only to find out it was on-purpose terrible kludge!
Try ansi-term instead of shell.
> The soft-line wrapping mode (visual-line-mode) goes crazy if the line gets really long.
Extremely long lines have been a problem in Emacs for a long time, however Emacs 27 includes so-long-mode, which mitigates it.
Like I mentioned, these are just a couple problems from a longer list. Occasionally, I pick one and (try) to solve it. If I tried to solve them all, I wouldn't have much time left for anything else. :-)
My more general point is Emacs is pretty janky.
I also don't think it's inevitable -- it's possible to make something that offers the awesome flexibility of emacs, but w/o the quality issues. Who knows, maybe Emacs itself will eventually evolve in this direction.
(Re a couple of your specific points:
- I just checked, and 36% of the files in my site-lisp directory are using lexical scoping.
- Dynamic scoping can be handy! Here's (incredibly nasty) my fix for the hard-coded 1-second delay in shell mode:
(flet ((sleep-for (&rest args) ())) ;; redefine sleep-for since shell calls it on purpose, guaranteeing a 1s startup time...
> My more general point is Emacs is pretty janky.
Well, for various definitions of "janky," perhaps. But I think your problems are mainly from third-party packages and your init file, not from Emacs itself. It's very common for Emacs to get blamed for badly written packages and code copied from random places. Such problems usually disappear by running `emacs -q`.
> I just checked, and 36% of the files in my site-lisp directory are using lexical scoping.
Maybe you meant the `lisp` directory? `site-lisp` is for site-local files, e.g. ones provided by the distro packagers and sysadmins, not by Emacs itself. I have a single file in my /usr/share/emacs/26.3/site-lisp directory, `subdirs.el`, which contains, in its entirety:
(if (fboundp 'normal-top-level-add-subdirs-to-load-path)
(normal-top-level-add-subdirs-to-load-path))
About the same percentage as you mentioned use lexical-binding, yes. Patches welcome, I'm sure, although I wouldn't expect a noticeable performance improvement by changing them to do so.
> Dynamic scoping can be handy! Here's (incredibly nasty) my fix for the hard-coded 1-second delay in shell mode:
That is pretty nasty. ;) There are two better solutions:
1. Use ansi-term instead of shell. ansi-term is the better shell package included in Emacs. AFAIK there's no reason to use shell over ansi-term. Just call `M-x ansi-term RET` instead.
2. Generally, use advice rather than `flet`. But I can't recommend advising `sleep-for`, as that would be likely to cause problems.
And FYI (you may already know, but in case not), with lexical-binding, you would have to use either advice or `letf` with `symbol-function` to override functions like that.
> The fact that such a fix is needed, on the one hand, and that such a fix is possible, on the other, are emblematic of the both cultural and technical reasons that emacs is not more robust.)
FWIW, there is no call to `sleep-for` in my Emacs 26.3's `shell.el` file. I suspect you have a configuration problem, or perhaps you installed an Emacs that was packaged poorly, with ill-advised patches applied.
But on the other hand, emacs w/o 3rd party packages and personal customizations isn't really Emacs!
So I think it's fair to critique the quality of the software you end up with in practice, as a normal user of Emacs. Perhaps I should say the "Emacs ecosystem" tends towards jankiness, rather than Emacs itself, per se.
> site-lisp vs lisp
I meant my personal collection of 3rd party packages I have installed, which for some reason I call site-lisp, perhaps an abuse of the term!
My thinking was recent 3rd-party code wold be a better pulse-check of current practice than emacs itself, which I'd expect to have a lot of older code predating lexical scope. Interesting that they're about the same though.
> FWIW, there is no call to `sleep-for` in my Emacs 26.3's `shell.el` file
It turns out it's in comint.el, in (comint-exec). Here's the code:
;; Feed it the startfile.
(cond (startfile
;;This is guaranteed to wait long enough
;;but has bad results if the comint does not prompt at all
;; (while (= size (buffer-size))
;; (sleep-for 1))
;;I hope 1 second is enough!
(sleep-for 1)
...Certainly it is! There are many users who have used Emacs for decades who have only a handful of lines in their init files and no third-party packages.
> So I think it's fair to critique the quality of the software you end up with in practice, as a normal user of Emacs. Perhaps I should say the "Emacs ecosystem" tends towards jankiness, rather than Emacs itself, per se.
Yes, I think you should say that instead; that would be more fair and accurate.
Elisp is a forgiving language, and Emacs is a forgiving environment, so low-quality code is not always "punished" by failing to compile or run. So, as with any software you would run on your computer, you should use discretion.
The good news is that the quality of software in the Emacs ecosystem is steadily improving. MELPA is upholding higher standards for packages, and more tools are being made to catch poor-quality code and encourage best practices.
> I meant my personal collection of 3rd party packages I have installed, which for some reason I call site-lisp, perhaps an abuse of the term!
Ah, I see. Not necessarily an abuse, if you are your own sysadmin, I guess. :)
> It turns out it's in comint.el, in (comint-exec).
Thanks, that's interesting. I guess there must be some interesting discussion on emacs-devel about that from years past. I wonder if that could be improved.
...
> Yes, I think you should say that instead; that would be more fair and accurate.
Makes sense, & will do in the future!
> The good news is that the quality of software in the Emacs ecosystem is steadily improving. MELPA is upholding higher standards for packages, and more tools are being made to catch poor-quality code and encourage best practices.
Good to hear. :-)
Getting Emacs is a journey. For me, it took years to get to the point where I discovered just enough of it to say with absolute certainty. In essence, there's simply no other software product in human history that has that level of extensibility.
Oh, I was not too fond of it in the beginning. I hated people praising it all the time. I hated watching people doing some mind-blowing tricks of text manipulation or some other productivity stunts. Just like you, I've deleted it with a promise never to try it again. But unlike you, I reinstalled, tried, and angrily deleted it again, and did that numerous times.
Before Emacs, I've used several different editors and IDEs - from Borland Delphi and C++Builder and a bunch of different versions of Visual Studio to Sublime Text, Atom, Vim, and finally IntelliJ. OMG, I loved IntelliJ. I used it for about seven years quite extensively. I used it to the point where it became my hobby to find some poorly documented features of it. I've submitted a ton of requests on YouTrack for improvements and bugs I found. I still get email notifications for those of them that never got addressed, yet people see them and upvote them, even after so many years.
Somehow, my curiosity kept bringing me back to Emacs. Luckily, every so often, I would meet someone who'd show me some cool Emacs stuff, and that would make me angry again - "am I really so stupid that I can never understand this piece of s... oftware?" Countless times I would try to "fix" my Emacs config, because "why this shit doesn't work?".
At some point, I had to keep at least three different things open all the time - IntelliJ (my main driver), Sublime/Atom/Vim, and Emacs. And one day I decided - I have to do something about it. There was too much frustration from context switching. And since I already knew IntelliJ very well, I decided to give Emacs a serious stress-test.
I promised myself that for one week, I would try to use Emacs and only it. And whenever I would need to do something, I would find a way to do that in Emacs and ignore my temptation to go back to the warmth of my cozy IDE. The first week was tough, but I survived. The second week was exhausting. After a few weeks, I was almost comfortable. I kept downloading and installing IntelliJ EAPs for some reason, maybe out of fear that one day Emacs would break so badly that I would have to abandon it again. Or maybe because I was sure, one day I will find that pretty major thing that Emacs just can't do. Oh boy, I've proven to be wrong. Over and over again. It turned out - not only Emacs could do anything I needed, it would do it better. A few months later I got a new job, a new computer. And at some point, I realized that I've never installed IntelliJ, but I'm still very happy. I have outgrown it.
- "Cool story, bro," you might say, "but how does that help me?"
I don't know the definitive answer. Emacs is an incredibly hard sell to uninitiated. You have to be tenacious. But I know for sure - learning Emacs is absolutely worth the initial pain and suffering.
Are certain extensions slow? I won't say "no", because there's a ton of them out there, which is probably part of the problem here: My Emacs isn't your Emacs, my set of extensions and modifications isn't yours, and, therefore, my experience with Emacs isn't yours.
I don't find Emacs clunky, but I like chorded UIs and I know the basic Emacs workflow by muscle memory at this point. I can't say if it's clunky or not because my hands know it, so I don't think about it anymore. There was a time when I didn't know it that well, so it was clunky for me, but I would have gone through the same period with Vim.
My big reason to stick with Emacs is that it's stable. There's a stable core, composed of C and the core Emacs Lisp libraries, which is unchanging, so my muscle memory is never punished by someone deciding that keys should work differently now so we're going to improve all of them you're welcome. I can keep my configuraton files and my hands and everything continues to work, which seems to be counter to the trend of modern productivity software.
Also, it doesn't seem quite fair to blame Emacs for inscrutable interaction between third party packages, rather than blaming the packages involved in the interaction.
If you do ever try Emacs again, hold off on using third party packages. The bar for getting a package admitted into Emacs is higher than just putting it up on GitHub, so naturally the built-in packages tend to be more robust on average (which is not to say there aren't many excellent third party packages, there are!, but it's reasonable to be more weary of them than of built-ins).
Also, could you say a bit more about how you found the Emacs documentation puzzling? I love the documentation, it's thorough and very readily accesible. I don't use IDEs (because I have no use for them) but if their documentation is even better than Emacs's I might play with one just to enjoy the documentation.
(Finally, if you meant Spacemacs's documentation ignore the previous paragraph: I have no idea what its documentation is like, I was only talking about Emacs.)
Of course, I don't really use it OOTB, I mean, I do have a configuration. My 700 line init file installs some 20 third party packages from MELPA, and changes a lot of defaults. I've also written about 1200 more lines of Emacs Lisp distributed among some 25 tiny packages I use. But I did start with Emacs OOTB and never thought it sucked, I thought instead, over and over, that some minor aspect could do with some tweaking. :P
And not locking yourself to Emacs's slow release cycle is a perfectly valid reason for not wanting your packge to be built-in. I don't think there is anything wrong with the fact that many excellent third party packages will never be built-in.
"happily using vanilla Emacs" indeed.
But that has accumulated over the course of about 10 years, so its really not a lot. And the possibility of having everything just the way I like is what drew me to Emacs in the first place! A shorter config would be an indication that either (1) I happened to like everything exactly the way it was by default, or (2) annoyances can't actually be fixed. I don't think any software could fall into (1) (right?, there's always something you wish were slightly different, or something you want to automate) and Emacs, unlike most programs, does not fall into (2).
Also if you saw my configuration and compared it people who use Doom or Spacemacs, or even just Helm or Ivy, you'd think my Emacs is very vanilla.
The Emacs community does not seem to have converged on a particular documentation idiom so there is a wide range of documentation quality for various configuration use cases. Most of the time I ended up finding bits and pieces of answers on Stack Overflow or other message boards, and proceeding with a lot of trial and error. That is fun sometimes, but not all the time; it was a rare experience when the documentation really nailed it for me. There does not seem to be much thought to the user experience on the whole.
Doesn't sound simple at all (compared to Notepad, anyway).
You think I was talking about doing all that manually?
I've long struggled getting Emacs to interop with all things Mac, and so happily pulled down Spacehammer to give it a shot. It seems snappy and generally like a Good Idea, but whenever I try one of the configured Emacs-related commands, it briefly pops open a new Emacs GUI window and then immediately closes it. Nothing useful seems to come from Messages or Warnings.
I don't suppose you've run into & dealt with this or similar, or have any ideas? I'd love to use Spacehammer.
Basically, both Hammerspoon and Emacs have to know about your activity of editing. Spacehammer handles Hammerspoon side, in order for that thing to work with Emacs, you have to import spacehammer.el package in Emacs.
Let me know if any additional questions arise.
You're spot on!
I'm using Emacs for todos, project management, meeting minutes, quotes, invoices, accounting, mails, chat, programming, configuration management, slides, documentation and so much more. As long as the task is primarily based around consuming or producing text, it's incredible how much more performance a solid foundation yields.
In case anyone is curious, here's my config: https://github.com/munen/emacs.d/
I firmly believe we're just in a bad place on the whole in terms of IM/voip systems for personal use and org use. Nothing is really good enough. The only ones that live up to expectations are mumble and IRC - the absolute no-nonsense of them leaves expectations low and exceeds them. Had slack taken a more open route and stopped being so org focused it had the potential to do really well (in the "good ecosystem" sense, not in the financial sense as clearly they're doing fine.)
Nothing bridges the gap between personal social use, informal org use (gaming, loose projects), and actual org use. How is it that mumble and teamspeak etc. are still far superior voip clients to literally all other offerings, including the well funded and supposedly mature discord which should be excelling here. Only thing mumble/ts can't do is replace voip telco systems, which in fairness nothing else does either.
Slack can't do voip for shit, discord can't even do notifications, irc can only manage offline message history if you're highly tech savvy or pay for it, whatsapp requires a phone with an active connecion and is clumbsy for ephemeral groups (telegram is fairly similar), gitter doesn't even come in to the picture, matrix has the shittiest public servers in the history of technology, xmpp is esoteric gobbeldygook.
The whole space is a mess.
If IRC in emacs is not your cup of tea, I would recommend the web client/web server The Lounge[1], which as far as I'm concerned gives people everything they want out of slack, in IRC, but doesn't lock you down to a proprietary protocol.
[0] https://github.com/jorgenschaefer/circe [1] https://github.com/thelounge/thelounge
Thanks for linking to Circe. I didn't know about that and will happily check it out. thelounge also does look really nice!
Having said that, the IRC client ERC which I'm using works well with regards to inline images. Here's my config for that: https://github.com/munen/emacs.d/#irc
Disclosure: I used to love irc in the 90s, then stopped using it in the 2000s (aughts?), and now am a superfan of matrix.
You've guessed what we're using the last couple of weeks. So far, I like it! It's come a long way. I've tried it a couple of times, but now even the web client works reasonably well.
And yes, of course - alphapapa software is always the best option!(;
P.S.: Nice nick! After waiting 20 years, I just watched the trilogy (extended version) with my wife last week. It's been a blast and it aged really well.
If you're a fan of makings-of, you'll love the extras on these DVDs. There is some seriously interesting work they did on CGI, AI, motion capture, 3-D scanning, et c.
Sometimes I wonder whether the situation would be better with specialized CLI IM clients running inside Emacs's shell mode: it works well for telnet MUDs, at least.
Possibly, but why do we need the feature when the website could simply use black text on a white background? When websites start doing things like this or not displaying static text when javascript is disabled, then I just skip over it.
Its not that it is hard, but I just can't get over the fact that it seems to not work very well. Buggy, slow, bewildering documentation, fresh installs that are broken, it all wears me down.
There are tons of code written in Emacs-lisp on Github alone. None of them, not a single developer contributed to Emacs ecosystem, has ever gotten paid, except for a few, small, voluntary donations. Almost all of that work is done by individual contributors. If you think about it, Emacs, to a certain degree, defies any logic - the way how it's concocted shouldn't work at all. Yet, it does, and some features of it done is a particular, astonishingly clever way, that no other IDE or editor has ever successfully replicated them.
To become a serious Emacs user, one has to either choose to be austere and handpick the packages to use or has to become really good in debugging the problems when they arise. Learn Emacs lisp, learn how to use built-in profiler, "toggle-debug-on" functions, learn how to investigate slow/failing startup, how Emacs loads packages, and you can update things with no fear.
Yes, sometimes things break (show me a software product with no bugs), but for me, it never takes longer than a few minutes to either find a fix or a workaround. From my perspective - Emacs is very stable.