1. 22

  2. 24

    I tried Spacemacs for a bit, but it broke almost every time I tried to update or install on a new system. I then tried DoomEmacs, which seemed like a step in the right direction, except that had it’s own suite of problems. Overall my general impression of Emacs is that it’s a bloated piece of legacy software that people keep tacking things on for reasons that I can’t understand. I see VSCode going the same route, just in JS instead of Lisp and C.

    1. 18

      Emacs is that it’s a bloated piece of legacy software that people keep tacking things on for reasons that I can’t understand.

      Because it has everything I need, except that one little thing, and I can tack that one on by just whipping up some Lisp functions. What’s so hard to understand?

      1. 3

        The idea that everything needs to be crammed into the text editor is the concept that I don’t understand and does not work for me. I don’t care if it works for you, but my experience with emacs has not been pleasant and I do not intend to go back.

        1. 5

          It helps if you think about it kind of the otherway around. It’s a highly flexible tool that also has a text editor.

          1. 4

            The idea that everything needs to be crammed into the text editor a single program is a concept that I don’t understand and does not work for me.

            1. 8

              You know how people make jokes like “Emacs is a great operating system; if only it had a good text editor”?

              It makes a lot more sense when you realize that’s not actually a joke.

              1. 6

                Did you ever try “vanilla” Emacs? (+EVIL if that’s your thing? Non-modal editing is half the reason why I use Emacs but that’s obviously just a personal preference)

                I’ve used Emacs for a very long time and a few years ago I thought I’d give Spacemacs a try, largely because I was thinking of declaring .emacs bankruptcy and having everything pre-configured looked like a good idea. My experience mostly matched yours – lots of things kept breaking, and since the whole thing is pretty complex, it broke in ways that I didn’t really want to debug. Figured I’m way better off just doing my own thing. Most things are pretty plug’n’play these days, I just (require some thing or another, and the rest is my personal configuration. My current emacs config files, which cover the (very substantial) subset of spacemacs that I use, are maybe 300 lines, at most? And I can’t remember the last time I “fixed” something in it.

                I tried mg and some uemacs flavours back when I was going down the suckless rabbithole and valiantly avoided bloat in the name of purity and Unix philosophy. Nowadays I kindda like emacs’ “bloat”. It’s not like I activate all of it and every piece of bloat is one less thing that I have to write myself when I need it.

                1. 1

                  If I recall I tried a minimal setup with just a package manager and EVIL mode, but still didn’t really care for it. The default emacs keybindings don’t work for me, they make my hands hurt so I at least need EVIL mode.

                  My comment about emacs bloat is also both about the plugin ecosystem and the codebase of emacs itself. Even the emacs developers are afraid to touch certain parts of the code (in particular, the rendering engine) because it’s overly complicated and brittle, and that’s also caused some issues for me.

                  1. 2

                    Why the “plugin ecosystem” (by which I assume you mean packages)? Sure, you have comprehensive and extendable modes (Org, Gnus, SLIME, etc.) but most packages really aren’t “bloated” in any sense of the word.

                    And the issue with the rendering engine is historical/related to the fact that emacs has multiple front-ends. The reason it’s not experimented with too much is so that issues are avoided, so I’m not sure what you’re talking about?

            2. 3

              If you look at what one does on a computer, perhaps in the past more so than now, a lot of it is manipulating text.

            3. 1

              And why do you need a terminal emulator and a calendar in a text editor??

              1. 6

                In case you’re serious:

                A terminal emulator with editing abilities is actually quite nice. In Eshell, for example, I can search output, highlight certain patters (either manually or automatically) or “flush” the output of a previous command. Copying and editing is just as easy The same is true for any debugger or a repl.

                And I guess I could live without a calendar, but I still like to have it because it’s not part of a text editor to me, but an iterative computing environment, just like a DE to some and a shell to others. And having something like a calendar or a calculator integrated into a unified workflow is something I think even non-Emacs users can relate to.

            4. 3

              it’s own suite of problems

              Like what?

              1. 5

                The UI would randomly break (especially with Magit), EVIL mode would occasionally fail to switch modes properly and space (the default leader) couldn’t be typed, as it would activate the leader UI in all cases and never make it into the buffer as a character. That last issue was a problem with Spacemacs too.

                1. 3

                  The UI would randomly break (especially with Magit)

                  With or without Evil?

                  1. 8

                    With Evil. I never ran without it, it’s whole reason I considered Emacs in the first place. It easily has the best vim emulation layer out there. Every other one I’ve used has had quirks that made them virtually unusable for me.

                    1. 3

                      magit was built without evil in mind, in fact, if it’s not because of vim, there’s no reason for evil at all

              2. 3

                Overall my general impression of Emacs is that it’s a bloated piece of legacy software that people keep tacking things on for reasons that I can’t understand.

                Its worth pointing out just how old Emacs is. Emacs was first release in 1976 making it 44 years old. So for comparison lets take another editor that was released the same year: vi. vi has had major re-implications and forks to add additional extensible. Emacs has been largely unchanged but changes the internal components that make up the editor.

                1. 4

                  There have been many forks of Emacs over the years; that we have (basically) only one implementation now is just an artifact of history.

                  1. 4

                    Yeah very true. I actually mentioned this in my original post, but I edited it out because I had 3 paragraphs of text where I said very little.

              3. 8

                So wait, upon Emacs you have a Vim virtualisation layer, upon which you have a VSCode compatibility layer? I think you overestimate how difficult Emacs keybindings are ^^

                1. 10

                  “Yo, we heard you liked editors, so we put an editor in your editor in your editor so you can edit while you edit.”

                2. 6

                  This is besides the point, but when the author describes discovering and settling on VSCode, then:

                  I continued using VSCode throughout my college life and during internships.

                  How times flies…

                  (The initial (non-preview) release of VSCode was November 2015)

                  1. 1

                    I had a hard time making sense of the author’s timeline… He talks about learning C++ in an MS-DOS IDE, but then used VSCode (which is only 5 years old) throughout his college years… So either he went to college much later in life than most people or his first computer was technically obsolete for two decades before he owned it.

                    1. 1

                      In third-world countries, Borland’s IDEs were popular in education for long past their sell dates. I know it’s the case for Russia, at least.

                  2. 2

                    Recently I’ve been increasingly interested in moving to emacs+EVIL. I’ve been a long time vim user, I also use IntelliJ+Vim bindings. The main draw of emacs is the programability that everyone seems to talk about. Did you find a productivity boost going to emacs?

                    1. 5

                      I’ve moved from Emacs to IntelliJ: Emacs is programmable, but its model is a buffer with text. In IntelliJ, you have access to full syntactic and semantic information, without any kind of regex kludges, and that is infinitely more powerful than Emacs. Programming IntelliJ is mich messier, of course, but scripting console exist, and writing custom extensions is not that bad. I did implement special purpose intentions couple of times. And, frankly, you rarely actually need to extend IntelliJ, because the feature you want probably already exist (like just ssr can do a lot).

                      Maybe in post-lsp world this kind of programmability will reach other editors, but it seems unlikely — lsp is intentionally on the dumber level of abstraction, it is essentially UI protocol, lacking semantic information.

                      1. 4

                        Yes, moving to Emacs helped me in the sense that I can now use the same interface to navigate all sorts of text, be it F#, Java, Perl, HTML, emails, R, shell scripts, or anything else. It integrates everything related to dealing with text into a relatively cohesive interface. I don’t have to struggle with application-specific keybinds, finding things in new menu locations, and whatnot.

                        The consistent interface is the key productivity benefit in my opinion. Commercial IDEs are still better at other language-specific things, like navigating a big, foreign code base, or applying automatic refactoring things. In my work, I still fire up the IDE for those things. But for just reading and writing code, I prefer the consistent interface I use for reading and writing everything text-based.

                        1. 3

                          Yeah, in terms of navigating between projects, files and making edits, I think this might be fastest I have been. Both due to the bindings and also due to it being faster than vscode imo.