> Not having a general text editor at your disposal for when you have to input/manage loads of text is like being a carpenter and only having a hammer in the toolbox.
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.
I gave Emacs another good-faith effort recently, via Spacemacs. I really bought into it, wanted to make it work, and forced myself to use it for all text editing. But despite every intention of working through all of the quirks and oddities and endless customization, and with the stated goal of reaching Emacs enlightenment, I gave up after a month or so, deleted it from my machine and resolved never to try again.
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.
I hate to tell you this, but it's not Emacs that's slow and clunky, it's Spacemacs. I dumped Spacemacs and spent a couple days building a new config with everything I used from Spacemacs and it is a good 10x faster.
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.
Agreed. I started with Spacemacs, which showed what is possible in Emacs. But it is so horribly slow and breaks so often that I couldn't use it more than a few weeks. Then I started with a blank init.el and just added packages (with use-package) as needed. Now it's fast and it still has the functionality that I need, things also rarely break (and thanks to Nix I can always roll back). The main idea that I stole from Spacemacs is the use of spacebar shortcuts (via general.el).
The thing about Spacemacs many people don't get - it does not liberate you from learning Emacs internals. The good thing about Spacemacs that it simplifies one of the most challenging things about Emacs - discoverability.
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.
> The hardest part of Emacs is to learn what Emacs can do, what it offers.
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.
> 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:
In that case, I recommend using `general`, which is designed to make configuring EVIL keymaps very easy. It also provides a `use-package` keyword. I use it for all of my keybindings even though I don't use EVIL.
Doom emacs I think demonstrates that have you can something all around nicer both form and function than spacemacs with absolutely amazing performance. My emacs install on a Sandy Bridge toaster with hundreds of packages configured is ready to go in about half a second.
Quality? I think Emacs (for what it does) is a product of superb quality. I just checked - I pull over 400 packages (including built-ins). Can you imagine Sublime, VSCode, or Atom with 400 plugins installed? I don't even know if you can find that many useful plugins for them, but even if you do, I think at best it would just hang them indefinitely.
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!)
> 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.
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...
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.)
> 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.
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:
In contrast, /usr/share/emacs/26.3/lisp contains 258 .el.gz files, from Emacs itself.
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.
On the one hand, you're absolutely correct that most of my problems are in 3rd party packages, my own customizations (perhaps), and their interactions.
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)
...
> But on the other hand, emacs w/o 3rd party packages and personal customizations isn't really Emacs!
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.
> 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.
...
> 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.
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.
Scrolling sounds like a terrible way to get around a file. I'd much rather be presented with a prompt to go to a named "section" with completion (an actual section in a prose document, or a function definition in a program), or to search for some text. Or, if I don't have a specific target in mind and I want an overview of the file, I prefer pagination to scrolling.
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...)
Clunky? Yes (adorably so for us Emacs lovers, but I understand this can be problematic for new users). But slow? That doesn't sound like Emacs, it's probably some misbehaving third party package included in Spacemacs that made it feel slow.
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.)
re: The documentation, I found the standard Emacs docs good enough to learn high-level Emacs concepts and such, but whenever I went searching for the nuts and bolts of how to configure specific bits of functionality, the documentation I stumbled upon (it's rarely easy to discover) either a) assumed a high level of proficiency and understanding of Emacs internals, often accompanied by (or consisting entirely of) large snippets of Emacs LISP b) was written in a kind of reference style that failed to give much context or help the user along in any way, or c) would be contradicted or superseded by some other piece of documentation, usually because of subtle package incompatibilities (probably exacerbated by Spacemacs in my case).
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.
Emacs OOTB sucks and some of the most useful packages will never be built-in, because developers don't want to deal with license assignment and locking themselves to the slow release cycle of Emacs. Also the community can be discouraging.
"Emacs OOTB sucks" People say that, and those people are entitled to their opinion. (A word of warning: I think many people who say that are not actual Emacs users.) I'll keep happily using vanilla Emacs while people complain about it, though.
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.
Well, you're right, it's not so vanilla anymore. :)
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.
Overall, I think it's a pretty fair assessment. Emacs is dense, obscure and what is these days called "opinionated". You gotta remember though, that Emacs is from mid 70s. There's a lot of legacy there, but also a lot of refinement. Lots of brilliant people have spent a lot of time improving it over the 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.
Well, there are lots of customizations doable (I’m still rocking my .emacs from the 1990’s going through several platforms, Linux→MacOS→Linux, refined over the years with custom functions etc.) but to name a single example:
my keyboard does have a Find key, and I tried mapping isearch-forward to it instead of the default CTRL+S.
That’s trivial, but then, you know how you can press CTRL+S again to go to the next result? Well, that key combo is hardcoded in LISP.
So yes, you technically can remap isearch-forward, but in a useless way.
What HNer henry_flower neglected to state explicitly in his helpful comment is that it is false that pressing C-s to go to the next result is hardcoded in some Emacs Lisp function. I just wanted to say that in case non-Emacsers don't know it's implied by what Henry did say. (What he said is much better than just "that's not true!", he also tells you how to change the C-s key that goes to the next match.)
Emacs is fast and responsive in my experience, as I'd expect relatively small software to be; the old jibe was Eight Megs And Constantly Swapping, after all, but if your system can't devote eight megs of RAM to a text editor you've got other problems.
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.
It is an accurate and absolutely fair assessment (from a perspective of someone new to Emacs), and I wouldn't even try to convince you otherwise. Probably nobody has ever fallen in love with Emacs right away after trying it for the first time. There's no "honeymoon period" with Emacs, and there's no "Learn Emacs in 21 days."
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.
I legitimately don't know how people can code without using some emacs or vim commands. Even the simplest stuff like M-f/M-b or C-a/C-e are so ingrained in how I use a computer. Do people genuinely not use them? Do they just navigate with the mouse and arrow keys? I suppose there's alternatives like Cmd-<left> and Cmd-<right> or Alt-<left> and Alt-<right>.
M-f/M-b = Meta-f/Meta-b (the Meta key is usually mapped to the Alt key on typical PC keyboards): move forward/backward a word. In vim, the equivalent is normal mode w/b.
C-a/C-e = Control-a/Control-e: move to beginning/end of line. In vim, normal mode 0/$.
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.
I've been too busy with my work related duties. I need to update and improve the documentation. Sorry about that.
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.
Great; thanks! I'll poke at this some more. I'd been working under the assumption that the calls to `emacsclient` were somehow injecting `spacehammer.el` (and I don't really know how to debug elisp).
> simple - to copy existing text, call emacsclient, it invokes a function that opens a buffer and pastes the text into it ... press dedicated key-sequence
Doesn't sound simple at all (compared to Notepad, anyway).
This is brilliant! Not so much for use of emacs or libpurple or bitlebee specifically for that matter (which are all fine)...Rather, what i find to be the coolest is the whole... "I'm gonna use my preferred text editor to interact with the world" approach!
Some might say that this reduces outside systems into nothing more than an API-sort of layer, but honestly, I really like that; it helps with learning curves, general adoption, etc. Kudos!
Op here. First, let me say: Thank you for the kind words
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.
I initially read this as the Spanish word “todos,” which translates as “everything.” The rest of the comment goes on to support my initial interpretation. I love it when things work out that way.
I agree. The joy in using emacs for (mostly) everything is my configurations and workflow translate nicely into other contexts as well. For example, all my evil mode (vim) config, custom keybinds and extensions are available whether I'm writing code, emails or chat messages.
Slack is working hard to prevent this kind of interoperability; the incentive for them is to push ahead on features, and being abstract-able behind bitlbee or libpurple impairs that. They have deprecated the API token (called a "Legacy Token" on their site) that bitlbee uses, and there's a sunset date of May 5 2020.
Fortunately it sounds like the tokens used by emacs-slack are supported. If not then I am going to start pressing for my company to leave Slack. Life is too short to use a browser UI instead of Emacs.
Yeah, that was a frustrating day for me. I went from running all of my IM through my IRC client, to being forced in to a combination of my IRC client and the slack desktop native app, to eventually giving up on slack altogether as it was heavy and finicky, providing nothing more (for me) than any simple IM client.
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.
Cann't bitlbee switch to that scheme Ripcord uses, with an auth token taken straight out of a web request to "normal" Slack in the browser? Or is Slack going to plug that hole as well?
For a more feature-full emacs IRC experience, I would recommend Circe[0]. It even supports showing images inline like slack.
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.
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
My prediction is that at some point in the future, those folks who have historically loved IRC (and there's nothing wrong with that!), will eventually begin to prefer matrix as opposed to, say, slack, mattermost, etc. Not necessarily for tech superiority, but for what I'll call the coziness factor; they'll just feel cozy using some matrix client, as they felt comfy using an ol' irc client. (Yes, yes, i know there are numerous existing irc-bridging apps/services natively supported by matrix protocol. ;-)
Disclosure: I used to love irc in the 90s, then stopped using it in the 2000s (aughts?), and now am a superfan of matrix.
It's cool to see Matrix work inside emacs but I think the spirit of the OP alludes to putting a little emacs in Matrix too. Composing messages in that band-aid at the bottom of Riot is a great example of a stress-inducing UX. Some venues around Matrix deserve high quality content and it's difficult to encourage that when people write and proof posts through the peephole.
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.
> 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.
I can confirm that it takes a bit of elbowing around, but you can get matrix-client.el to work with pantalaimon in its current state. extending the client to "know" it needs to talk to localhost rather than the server half is most of the stuff I had to hack on to make it work.
I'm using a similar setup and for similar reasons, particularly for XMPP, but finding it hard to recommend to others because of the awkward bits involved (and because not everyone uses/prefers Emacs, of course). It's mostly okay for basic textual messages over a stable connection, though even then an IRC client is likely to split outgoing messages assuming an IRC message length limit. But when it comes to anything more advanced (e.g., file transfer), less visible (e.g., proper connection closing), or requiring a more advanced UI, it leads to compromises at multiple stages: similarly to just bridging protocols in general, but with addition of bitlbee/libpurple API restrictions.
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.
Surely everyone knows about Reader mode by now? More seriously, is something like Firefox's Reader mode available as a plugin to Safari? I can confirm that it is for Chrome.
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.
I might recommend that people who have set up Discord or Slack or Matrix or whatever should set up their own IRC server to bridge with it, rather than the end user setting up their own.
Every 6 months or so I do the vim<->sublime<->emacs dance. I really want to like emacs and really believe in its central tenants.
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.
It certainly may appear to be broken all the time. But that's the price you pay for using the vast Emacs ecosystem. Emacs over the decades has accumulated an incredible amount of things - built-in and third-party packages, different ways to work on various platforms, protocols, screen-sizes, languages, etc.
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.
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.
---
¹ https://github.com/agzam/spacehammer
² https://github.com/agzam/exwm-edit