75 ms·

Making Emacs Popular Again (2020)

• bitwize 5y ago
  I still feel the same way now about this article that I did then: Popularity is a misguided goal for Emacs. Emacs is a hacker's editor. Back when I started using it, the OS I ran it on -- Linux -- was niche, and the editor itself was niche of the niche. It seemed to come with "power users only" signs guarding it. It had its own diskset in Slackware because it was big and heavy and not the kind of thing every Linux user needed to have so you could easily exclude it. It's designed to be shaped into a custom tool that does what you need the way you need it done, as you work with it. Not everybody works this way, not every programmer works this way. Many enterprise shops aim for a software factory approach where there is one common, blessed workflow and you train people in that workflow and just plug them right into the assembly line. Those people make up the vast bulk of developers and most of them wouldn't know what to do with an Emacs if they had one. And that's fine. When those people start crossing over onto Emacs mailing lists and going "What Emacs needs is to work exactly like my favorite IDE, else it will die in obscurity" I'm just like, psh. Go away. You've got your own great big ballfield to play in, why do you feel the need to come in and start trying to set rules for our little one? In fact, this reminds me of a story. Back in the early 2000s there was a clown called Scott McCollum. An ultraconservative, he was fond of writing articles about how Linux and open source were communist cancer. McCollum had an acolyte named Joseph D. Wagner, who once trolled the gcc mailing list with a bug report about a TOTALLY CRITICAL SECURITY VULNERABILITY wherein gcc's optimizer would remove code to scrub sensitive data such as passwords from a buffer before reusing the buffer. When he was told "that's what 'volatile' is for" and to go fuck himself by the gcc maintainers, Wagner had an op-ed published on McCollum's site wherein he went "AHA! The open-source commies maintaining gcc don't care about your security! Use Microsoft Visual C++ if you want your software to be secure!" Because of people like that, I don't trust entryists from outside a community. I have reason to believe there's a good chance they're not acting in good faith for the benefit of the project.
• throwawayswede 5y ago
  I'm happy that Emacs community doesn't have a lot of those who think that "everything should be easy" and that working hard to learn something is a waste of time by default. Emacs is great with or without your usage of it.
• aww_dang 5y ago
  Who is actually using the GUI elements mentioned in the article? Emacs is a comfort zone where I don't need the mouse. >...buttons could be improved with rounded corners...
  • WalterGR 5y ago
    You don't need the mouse to use GUI Emacs.
  • sokoloff 5y ago
    I’m a 30-year user of emacs. I still pick up the mouse to do something in emacs at least once a month.
  • thom 5y ago
    I would worry if people started moving away from Emacs as text-centric. My biggest complaint with VSCode (which I do fully expect to take over and to which I will one day presumably have to migrate) is that there's so much damn UI for things. The terminal window isn't just a buffer of text like everything else, it's its own ungodly window that pops up differently. Most extensions are primarily UI instead of keyboard and text driven. There's a nice Magit clone which does things properly, and I'd love to see more effort on things like that. But fundamentally VSCode doesn't seem to have the right level of abstraction to allow all this.
    • justsomedood 5y ago
      This is the exact issue I have with VSCode. I don't particularly like the keybinds in emacs, but the killer feature for me is that everything is a text buffer. Eshell, magic, lsp, I interact with them all in a similar way from the keyboard. It was the terminal in VSCode that brought me back to emacs
    • thrower123 5y ago
      The problem with VS Code is there is *not enough* UI. I desperately would like to have some toolbars and menu options, because the kotkeys and key-chords VS Code uses, where they aren't following conventions, are not easily discoverable. They're in a bind because they are trying to straddle a market where you've got emacs an vim users to one side and Visual Studio users to the other. Some ability to customize the UI, even if it were provided by a plugin, would be helpful.
• rich_sasha 5y ago
  I’m surprised at the disparity between Emacs and vim use (20% vs 3% according to some survey). I thought it’s more equal. I suppose, while the learning curve for Vim is a lot steeper, you reach the power regions very quickly too. With Emacs, while it’s less alien initially, you need to learn quite a bit more to get to “power user” levels. But then, in turn, it seems that Emacs is much easier to mold into an IDE sort of thing, whereas this seems against the Fu of Vim. One tool, one purpose.
  • lgrapenthin 5y ago
    Its quite similar percentages to about a 10-15 difference of IQ points at end of the distribution curve. https://commons.wikimedia.org/wiki/File:IQ_distribution.svg https://commons.wikimedia.org/wiki/File:IQ_distribution.svg
    • deworms 5y ago
      You'd expect more intelligent people to prefer a tool that doesn't require days of tuning to start being remotely usable though
      • rich_sasha 5y ago
        Jokes aside, definitely not a day's worth of tuning. My minimal set-up is mostly hiding all the GUI elements. Though I also make a semi-virtue out of trying to use as much vanilla Emacs as possible, for this very reason. If you know your way around it, there's a lot of power in unmodded Emacs still.
        • SauciestGNU 5y ago
          Stuff like electric pairs, rainbow delimeters, rjsx-mode, prettier, and neotree are really all I use. I started using emacs because of auctex writing my master's thesis, and ended up switching from vim because of the experience. Once you know the basics about packaging (enabling melpa) and setting a comfortable theme you're pretty much ready to roll.
• sofunnytotell 5y ago
  so you say: emac users are, well; conservatives... (( use controversy ))
• ho_schi 5y ago
  The complain about the weird and twenty year old issue in Gtk questionable[1]. Gtk2, X11 and disconnecting a display and Emacs calls abort(). I cannot speak about EMACS because I prefer VIM and NEOVIM. My requirements are usability - where VIM excels with your knowledge (learning curve) - and LSP-Support. The later is provided since NEOVIM '0.5`[2] nearly ready to use. A modern editor should know what the user is actually doing and interact with the compiler, spell-something (languagetool?) or whatever :) LSP with NEOVIM? Requirements: 1.) VIM-PLUG 2.) NVIM-LSPCONFIG 3.) NVIM-CMP Your compiler will provide everything. In my case CLANGD for C and C++. Setup isn't hard but I would appreciate a HowTo directly at neovim.io or even built-in NVIM-LSPCONFIG and NVIM-CMP within the package. Because figuring out is hard, setup is not. Where GNU needs to catch up quickly is LSP with GCC, the compiler doesn't provide a user back-end. This is important and actually I want know what GCC things about my code - I'm using GCC to compile. EMACS and VI-Family will greatly improve through this. You don't need to like Microsoft because of LSP - but LSP is great. [1] https://gitlab.gnome.org/GNOME/gtk/-/issues/221#note_577021 https://gitlab.gnome.org/GNOME/gtk/-/issues/221#note_577021 [2] https://github.com/neovim/nvim-lspconfig https://github.com/neovim/nvim-lspconfig
  • okasaki 5y ago
    Emacs does support LSP: https://github.com/emacs-lsp/lsp-mode https://github.com/emacs-lsp/lsp-mode
    • b3morales 5y ago
      Eglot is another excellent LSP client implementation: https://github.com/joaotavora/eglot https://github.com/joaotavora/eglot I slightly prefer Elgot's interface, which feels a bit more restrained, but both are excellent.
  • NoGravitas 5y ago
    Strongly agree that there should be a GCC LSP server, and that Stallman's objections to the GCC features that would be needed to make one are Not Helpful.
• jstx1 5y ago
  To be more popular Emacs needs to be easier to get started with and easier to extend. If I have to read a whole book or learn an entire new programming language, I'm not going to put the time in. If any time I search for "how to do x", I get a disjointed mess of "but spacemacs...", "in prelude...", "this custom elisp snippet..." where every piece of advice can be potentially incompatible with any past or future modification that I've done - then the effort and frustration doesn't seem worth for a text editor / org tool.
  • rvieira 5y ago
    I think Spacemacs helps with getting started. For a newcomer there is a "curse of Emacs", helm? ivy? ido? Wnat to do Python? elpy, lsp, etc It's easy to get confused and just give up. Having a curated config like Spacemacs helps to get it working out of the box IMO.
    • tharne 5y ago
      Doom Emacs is very good in this regard too. Without Doom and its sane defaults, I certainly would have given up on emacs.
  • cpach 5y ago
    When I set out to learn Emacs in the year ~2001 or so, I just did C-h t in order to launch the builtin tutorial. IMHO that can still be a viable way to get started. Spacemacs might be nice but it’s in no way required in order to be productive with Emacs. My personal .emacs file is only 32 lines long (28 lines of comments are not counted).
    • deworms 5y ago
      If you need a dedicated tutorial for a text editor it's a great sign that something is very wrong with its design, particularly concerning discoverability. Emacs has no user-friendly command names (you need to memorize function names which are often meaningless abbreviations), no autocomplete, and doesn't show available functions.
• deworms 5y ago
  Emacs should have been what VSCode is now - a powerhouse of customizability that offers unmatched functionality by default. Instead it's a toy for some old people who are still holding onto the remnants of an age that passed a long time ago. Emacs is basically useless compared to VS Code, and its authors are what's holding it back. I don't see it bouncing back to popularity any time soon. Anything you can do in Emacs, you can do in VS Code faster, better, and easier. Emacs is being steered by a committee of living fossils that look condescendingly on people who expect a text editor to be discoverable, easy to learn, and productive out of the box. They make passive aggressive comments ridiculing anyone who wants Emacs to behave remotely like any other program. With this kind of leadership, it will be dead in a few years.
  • underatree 5y ago
    > Emacs should have been what VSCode is now - a powerhouse of customizability that offers unmatched functionality by default. +1. Emacs is a powerhouse of customizability, and it needs to work on functionality by default. > Instead it's a toy for some old people who are still holding onto the remnants of an age that passed a long time ago. Emacs is basically useless compared to VS Code, and its authors are what's holding it back. I don't think Emacs is held back by its authors. The article might not make it clear but RMS does not contribute much to the vision or code of Emacs today. Read emacs-devel, and though there's occasionally some conflicts, the authors are keen on progress aligned with what people expect from an editor. Emacs is a complex platform, owing to its unique vision on blurring the line between user and developer. The authors do a great job of keeping that up-to-date.
    • deworms 5y ago
      If you need to use a specific dialect of lisp most people won't be familiar with, it does a poor job at it. Lisp is not a language many people use today. NeoVim lets you use any language you want for writing extensions. VS Code uses javascript which is easy to learn and most developers already know it.
      • underatree 5y ago
• jdblair 5y ago
  I've been using emacs for approximately 30 years. Every once in a while, someone ask me what editor or IDE I suggest they learn, and I never suggest emacs. It's incredibly powerful, but it's a fossil. I keep using emacs mostly because of muscle memory.
  • rjrodger 5y ago
    That's it. That's the reason. You can usually get Emacs key bindings (or a shallow approximation thereof) in most editors. But yeah, we're stuck, so I guess we just gotta double down. It is fun when the young 'uns do a double take after you execute a particularly fancy macro. I do love that.
    • MereInterest 5y ago
      I've customized my setup to the point where I don't just want emacs keybindings, I want my emacs keybindings. Because those are the ones that are in my fingertips.
    • jdblair 5y ago
      The macros are always the deal-breaker. I tried sublime text, set up emacs keybindings, then tried to ctrl-x-( to start a macro and... switched right back to emacs. (and then proceeded to modify me emacs config so it approximated many sublime text features)
      • azeirah 5y ago
        I used to be a heavy Sublime Text power user a couple years ago. I found out at some point that while Sublime does market itself as supporting macros, many commands were one of these four - extremely basic (ie, move left or right) - poorly thought out - Straight up not implemented as a recordable macro command - Buggy
  • mark_l_watson 5y ago
    Same situation for me, but much longer than 30 years. I still use Emacs with SBCL Common Lisp (but use VSCode if I am exploring someone else’s large codebase) and for routine non-programming editing, but otherwise I use IDEs: LispWorks, PyCharm for Python, IntelliJ for Java and Clojure, XCode for Swift, and Racket IDE for Racket Scheme. I like having Emacs key bindings for other editors and IDEs.
• deworms 5y ago
  If you need to install a dozen plugins (helm, projectile, company/autocomplete, flycheck, whatever else) to match something that's installed by default in any modern text editor, Emacs will never be remotely popular. Even something as simple as theming doesn't work by default; each theme needs to be implemented separately for every mode. 99% of people will see how fruitless it is to try to configure it and move on. Why waste time on fiddling with configs?
  • p2t2p 5y ago
    Exactly that, plus it doesn't really serve well as platform. I mean VSCode renders Markdown previews correctly, not some ASCII based approximation. It renders images if I happen to click on one. Extensions can actually provide decent UI, thank's to that CSVs never looked better in my text editors.
    • underatree 5y ago
      I use Emacs's markdown mode for syntax highlighting. I have never used live export, but looked for it in its dropdown menu, found it, and clicked it: https://i.imgur.com/0LG6nnS.png https://i.imgur.com/0LG6nnS.png It renders images and doesn't rely on ASCII for its rendering. I agree Emacs could benefit from some polish, on the whole.
      • p2t2p 5y ago
        I compared it two what I see in my VSCode (https://imgur.com/a/u9naqVi https://imgur.com/a/u9naqVi) and fair enough, it got way better since I tried it last time.
    • AlanYx 5y ago
      Both the examples you give seem kind of arguable; I'd almost say they demonstrate the opposite. The problem with VSCode's built-in Markdown previews is that they're not extensible, so there are a variety of alternate Markdown renderer plugins, for example to better work with the various wiki-like Markdown plugins. Emacs also has Markdown previewing, but it is extensible by design. I'm not an expert in either VSCode or Emacs (I use both off and on), but inline image handling seems like it works better in Emacs. I've never figured out how to show Markdown images inline in the actual text editor part of VSCode (as opposed to the preview), whereas that's super easy in Emacs.
• rbanffy 5y ago
  What I like about Emacs is the things you learn from it. The “config file” is a program, not a JSON or INI file. This allows the user to add functions to the editor very easily. For instance, one of the first tricks I taught Emacs to do was to find the right font size so I could have at least 80 columns on a window. It was a bit of work, and needs to contemplate some corner cases, but it’s really cool to be able to do that in your config file. This is a pattern other programs and frameworks use. It’s relatively normal in Python to import configuration from a settings.py file that’ll do whatever is appropriate to get the information (a bucket with an INI file, constants declared in code, a local settings_devel.py file…)
• CJefferson 5y ago
  Speaking as someone who sees a lot of students start using text editors for the first time, VSCode has two massive advantages over Emacs: 1) Most students already basically know their OS's graphical interface -- the "basic keys" like cut/copy/paste/load/save all work as expected. 2) The first time you load many common filetypes (like Java for example), a box pops up saying "Do you want me to install a nice set of standard Java plugins?" Both points are really useful for getting started quickly, but would I imagine be really hard for emacs. The first would require changing default behaviour on first startup, the second would need accepting some set of people to decide the "default" sets of plugins. For those who say "emacs is worth learning", that might be true, but when students can choose between Emacs, Vim, VSCode, nano, Intellij, pycharm, Eclipse, Atom, Sublime Text or Notepad++ (that's all the editors I think I've seen in the last year), they need a special reason to give emacs all that extra work needed to understand it. Vim/Neovim had a bump a few years ago and got really popular (although that might be over now, at least on my limited experience). I think that was because there were obvious improvements going on, which attracted students to take a look.
  • vintermann 5y ago
    Vim is different enough that when its fans say it's superior, at least some people think it's plausible enough that it's worth learning. And even if they don't become appreciably more productive by it, at that point it's sunk cost and they might as well keep using it. The last time I had any reason to consider getting into emacs, was when I came across a proof assistant many years ago that basically required it - it used emacs to provide an interactive interface. Not unlike how everyone uses electron/chrome these days to quickly provide a familiar interactive interface. It was like an exotic artefact from a parallel universe where emacs' conventions became dominant instead of IBM and Microsoft's.
    • wayoutthere 5y ago
      I personally love Vim because once you know how to work it, you can code extremely quickly. You don’t really even need any macros (though they can make you even faster) — I find the default commands to be fast enough that I consider vim to be an “expert interface” for text editing. Also love the VS Code vim plug-in.
• vintermann 5y ago
  Emacs' fundamental problem is that in text editing, there are many equally good ways to do things. It's equally good for Undo to be on control _ as on control z. It's equally good for scrolling to move the cursor as to not move it. It's equally good to have Lisp as a scripting language as JavaScript. No, really, I mean it. It's not a big deal in the big picture. And Emacs choose perfectly good, perfectly sensible defaults on all these things back when it came. (That can't be said about all editors from that time.) It's just that in the 30+ years since, the world has converged on other defaults. Every little thing is done different than you're almost certainly used to - yet not different enough that anyone can claim it's somehow superior (unlike its modal cousins from the same period. I think their claim is dead wrong, but at least it's different enough that they can persuade some).
  • isolli 5y ago
    There's nothing worse than reflexively typing ctrl+z to undo in Emacs and instead have the window disappear into the background!
    • ajross 5y ago
      In my .emacs since time immemorial: (global-unset-key [(control z)]) It's absolutely true that defaults are "bad" in many modern environments (though remember C-z to suspend in a terminal environment makes perfect sense!). But the nature of the editor is customization like this. People unwilling to do this just aren't ever going to be happy with emacs. And for those just learning, tricks like that (c.f. emacswiki.org) are a very reasonable entryway into a world of possibilities. I mean, look, Emacs isn't ever going to be VSCode. If you want VSCode, use VSCode. It's a great editor, and frankly at this stage I think nothing is going to do VSCode better than VSCode already has. Emacs is something different, and we might as well embrace that. (Not that I'd object to switching some of the dumb defaults around, of course. I just don't think that's going to help very much if your goal is "displace VSCode").
      • teddyh 5y ago
        Ctrl-z for suspend is useful in the terminal, though, so maybe something like this? (if window-system (global-set-key (kbd "C-z") 'undo))
• SirensOfTitan 5y ago
  I’ve used emacs for years, and then vim before that for several years. I maintained my own config for a while, then moved to doom. …while I eventually ended up abandoning notes in org for a dedicated tool, I love using emacs. My only issue is perf: on an M1 Max I get multiple freezes from LSP per day when working with typescript. I’m currently on the latest emacs-mac build (plus with native comp doesn’t seem to be that much better). The perf issues in a large typescript project are so severe that I’ve considered looking at other editors. A modern UI should just not lock up while waiting for a command to finish.
  • gjvc 5y ago
    Emacs 28 with native compilation is much faster for me on Linux. :-/ though there are hints of the GUI stuttering here and there.
• the_spacebyte 5y ago
  As an Emacs user for ~10 years the greatest deterrent is it being single-threaded and lisp. I just can't understand the love for it. I've spent countless hours customizing my own configuration and I just can't enjoy lisp. Emacs's source code is also hard to understand and contribute to (let's not talk about lisp.h). I'd rather have a new editor (or emacs fully re-written) with the same mindset as emacs - near-full customization via a modern scripting language (lua?) and/or c/cpp plugins, and text-centric. I don't care for fancy UI or buttons it could even have the same look and feel which I love
  • e40 5y ago
    > lisp.h Wow. Been using and extending Emacs for 40 years and I've never had to even look at lisp.h or hack the C code.
    • the_spacebyte 5y ago
      That was mostly a "tongue in cheek" joke : ) What I meant was that the code base is overwhelming both because it has some years on top and I don't like/understand lisp that much
  • gorjusborg 5y ago
    That an emacs user holds that opinion is a bit surprising to me, as to me most of the reason for me using emacs is to develop in lisp-inspired languages. I think lisp development is the raison d'etre for emacs in the modern times. As someone who loves fennel, clojure, scheme, etc., I find myself drawn to emacs because the (repl driven) workflow is so good. That said, I've found that I can't give up vi-style modal editing. The interface matters to me. So neovim it is, for now.
    • bsder 5y ago
      I'm going to go out on a limb and suggest that Lisp is, in fact, an albatross hanging around Emacs neck. Using Lisp (and especially elisp) is not okay. Lisp has some very sharp corners that simply are not acceptable in modern languages. I use Lisp when I'm very resource constrained but still need an interpreted language--otherwise I use anything else. Dynamic scoping is just stupid (fault of elisp). Not being to operate on a sequence is stupid. cons pairs to build everything is stupid. nil() terminated to signify lists is stupid. The pervasive necessity of metaprogramming macros is stupid. An inability to type things is stupid. Lisp/Scheme encased itself in amber in the 1980's and refused to keep up with genuine improvements in programming languages. Sure it meant they missed out on the collective brain damage that was design patterns and object oriented--but it also meant that it missed out on good things, too. Take a very hard look at Clojure and look at what parts of Lisp/Scheme Rich Hickey put a bullet in and which parts he kept. The Lispers still excoriate Clojure as "not a Lisp" and that perfectly sums up the problems with Lisp nowadays.
• aj7 5y ago
  This was super valuable as it showed me conclusively why Emacs is dead, except for a relatively small group of persons who were exposed to it very early in their careers.
  • tharne 5y ago
    > Emacs is dead, except for a relatively small group of persons who were exposed to it very early in their careers This is false. There are plenty of new users. https://emacssurvey.org/2020/ https://emacssurvey.org/2020/ Emacs is not now or in the future ever going to have "mass appeal" and that's okay. It caters to a niche, intellectually curious developers who like tinkering for its own sake. If programming is just a job to you, that's totally fine. For a lot folks, programming is like accounting, a safe path to a decent paycheck. These folks will likely use VS Code and that's OK. Not every piece of software needs to "eat the world". Some software, like Emacs, can just be enjoyed by a community of dedicated users.
  • NoGravitas 5y ago
    The joke "Generally Not Used Except by Middle-Aged Computer Scientists" has been around for like 20 years, though.
  • BeetleB 5y ago
    Emacs likely has more new users now than ever before. I'd wager the absolute number of users are clearly growing. There's an order of magnitude more Youtube videos, blog posts, etc than there were 10 years ago. Getting Emacs help via a Google search often failed me a decade ago. Now it's extremely rare that I don't find an answer.
• ashika 5y ago
  mass appeal is overrated. being able to use terminal mode over ssh is more useful to me than rounded buttons.
• gopiandcode 5y ago
  I see many people on here (likely non-emacs users) claiming that Emacs is obsolete/outdated/dying by completely misunderstanding its position in the ecosystem. Maybe it's easier to understand via analogy. Let's consider cars. Of the global population of car users, relatively few of them are F1 racecar drivers. Furthermore, you can easily make the case that the particular features (aerodynamics, speed etc.) that make the F1 a good racecar, would not be useful for the average driver - the time they spend honing their skills to handle such a beast, you could argue, would be better spent on other things. But, at the same time, the F1 car has and will continue to have a place in the car ecosystem. In the case of developers, you might be right that, for the average developer, working on your run of the mill, mundane, forgotten-in-a-few-years, CRUD web apps, a normal _average_ car (M$ vscode) would be a better investment, but no matter what, you will never be as fast or flexible as an F1 car (GNU Emacs).
  • btreecat 5y ago
    There is no world, in which "flexible" and "F1 Car" belong in the same sentence. By design, a track car gets rid of anything "flexible" for highly optimized choices. If we want to assign a car to emacs, it's more like a Toyota Tacoma, with no body. Rugged, flexible, some basic building blocks that function out of the box.
  • bch 5y ago
    I just love that for a moment here we’ve put aside our differences about emacs vs vi and focused our efforts on bike shedding which car analogy best fits. Peak computing culture.
    • skytreader 5y ago
      I wouldn't waste keystrokes on the classic religious war being waged in this thread so I'm gonna throw my hat in this arena instead. I agree with you---that analogy sucks. Being able to drive an F1 car comes with excellent financial opportunities. Even if I'm not "on the grid" (i.e., actively competing in the GPs), I can be a test driver. Heck the license required to drive an F1 car opens other doors in itself (maybe in other motorsports, but also allegedly the range of vehicles you can drive). In contrast, if I am proficient in emacs I am...proficient in emacs. I edit code in a manner that is visually impressive to maybe three persons in the CS department. I'd have an ever-so-slightly deeper connection to RMS than your average CRUD-slinger. I am out of advantages to enumerate and I'm trying very hard. Maybe text editors are about as similar to cars as apples are to buildings.
• Arubis 5y ago
  I understand why there's all this concern about making Emacs popular--as software professionals, we've all seen a few tools that we use and love wither at the vine and die slow deaths. But the concern for _overall_ popularity is a little misplaced. There's more developers than ever, and the pie continues to grow; Emacs just needs a sufficient total userbase to stay maintained, and that seems already to be in place. The greatest threat to Emacs, as to any other fairly well-liked open-source editor, is a paradigm change in how software gets built or run, not whether it has 7% or 9% mindshare.
  • Azsy 5y ago
    I was nodding along with the first paragraph. But then, > The greatest threat to Emacs, [..] is a paradigm change in how software gets built or run Is a little to far into scify land. First it requires software to no longer be text based, and then it requires virtually all software to switch to this non-text based solution. In that world a single user can keep Emacs up to date and compatible by asking our AI overlords to do it.
    • heyparkerj 5y ago
      I see where you're going - but I've personally noticed that there are a lot of things coming along with these cloud infrastructure paradigms that have made me feel like my localhost text editing workflows are going to make me look and feel even more like an absolute dinosaur as time goes on. I can't speak eloquently on this as I'm still an amateur to these cloud infra configuration concepts and their real limitations on how I'm used to thinking about application development, but I hope this comment sparks some inspiration for someone else to do so.
      • lpcvoid 5y ago
        Don't think of it as you being a dinosaur - think of it as you being a sane person making sane decisions about your development environment.
  • deltarholamda 5y ago
• joebergeron 5y ago
  Preface: I have been using Emacs as my only editor for over ten years. This article is at once extremely funny to me and extremely frustrating. Funny, in that it reads like a tabloid magazine article from an alternate reality where the goings-on of our savior RMS is the hottest gossip available, and Emacs is the topic du jour. Frustrating, from what I perceive to be an impenetrable thickness from RMS and RMS-adjacent Linux contributors/Emacs users. People who use text editors just don't care. (not to imply that they ought to care.) It's not just that Emacs, as it tends to ship, is extraordinarily ugly. It's not just that Emacs is difficult to master, or that it requires knowledge of Lisp to be meaningfully configurable, or that it isn't friendly to new users. It's all of this and many more. People use VS Code and Sublime Text and Atom and $EDITOR because they're simple on the surface, they're easy to install (you just download it and go), don't need heaps of customization to become useful, don't force the user into learning a completely new set of metaphors, etc. etc. The average developer just wants to write some code. This quote got it the most right: > [...] no Microsoft word user has ever considered themselves to have opened a "buffer". They open "files". They move "windows" around, not "frames." They cut and paste not kill and yank, etc. As long as core usage of the basic functionality of the software demands users learn a totally new set of concepts, develop new mental models, and develop intuition for new design metaphors, Emacs isn't going to win over (m)any new users. It doesn't matter how much Emacs users try to evangelize (what ends up amounting to,) their system of beliefs, or attempt to proselytize their design as "best", or most well-reasoned. Unless Emacs ditches its fundamental philosophy that it ought not to "baby" the user by natively offering familiar and welcoming design patterns and a de-facto feature set that people living in this century expect by default, I don't see Emacs gaining meaningful share. People use the alternatives because they simply don't care about the things that Emacs contributors care about. If, down the road, they end up caring, those alternatives do indeed offer plenty of reward for those who take the time to learn; it's just that with the alternatives, the ceiling is presumably much lower than for Emacs. On the other hand, the floor is much higher. With Emacs, the floor is somewhere around the molten core of the Earth. Meanwhile, you have Emacs core contributors quibbling about rounding edges and custom icons; unable to come to a consensus about all manner of trivialities, when what they really need is a seismic shift in core philosophy. It reeks of impending irrelevancy and a gives profound sense that Emacs is deeply out of touch with what the average person wants, as far as their mission of actually getting people to use the product goes.
• indymike 5y ago
  I've been using Emacs for the better part of 30 years. Right now, I use it less than ever. I've switched to using JetBrains IDEs for programming. JetBrains replaced VS Code which was nice, but required a lot of time dealing with plug-ins that the JetBrains IDEs don't. The full IDE with tightly integrated deployment, language tools, really advanced code completion, documentation, source control, debugging (and remote debugging), code profiling and project management is just 20-30 too many plugins to manage in most extensible text editors. I still use Emacs for remote text editing and org-mode, but that's it. The UI problems in Emacs are not a "round corners" problem. Emacs is a great console app. But GUI Emacs is sabotaged by it's excellence as a console app. Emacs' autocompletes, tooltips, forms and dialogs are more mid-80s terminal UIs than GUI native. I suspect putting a full, comfortable GUI on emacs is a hard problem. You can't even resize an emacs window with the precision you can every other app on Linux and MacOS (no idea on Windows) because it forces resizes based on line height and character width (or something that approximates that). In the end, Emacs isn't bad software. On the contrary, it is excellent, but it's excellent at being a text editor that is native to a terminal, that runs well as a GUI app. It still is very useful, but it is not competitive with newer ides and through the web capable editors.
  • CRConrad 5y ago
    > You can't even resize an emacs window with the precision you can every other app on Linux and MacOS (no idea on Windows) because it forces resizes based on line height and character width (or something that approximates that). Well, so does PuTTY, the (AIUI overwhelmingly most) popular remote terminal emulator on Windows. Which AFAICS is quite appropriate for a text-based program in a GUI window. So if there are problems with Emacs, I don't think that is among the biggest ones.
• butterisgood 5y ago
  Emacs is my daily driver for work lately. Oddly enough I don't use it for code editing as much as I do for reading (TAGS navigation is great!) But, for a lisp environment - it's outstanding! I use it to do complex Jira queries (jiralib2), and have even used the source to jiralib2 as inspiration for writing my own RESTful connectivity to two other proprietary in-house systems. Then I cross reference them, to find out what stuff needs my attention immediately. There's no amount of email notifications, or slack bot popups that can replace what I'm doing for my workflows every day that I can get done in Emacs right now. Basically I create a lisp-interaction mode document, and treat my lisp expressions like things I can expand in a report by C-j'ing them. Then I've got keyboard shortcuts to open things in brower tabs using eww's functionality. I did a demo video for a few coworkers and folks who'd strayed from Emacs are starting to think about coming back to it again. I started kicking around the idea of building this out again in Racket, just to learn Racket, but it's a distraction from the system that's working great for me right now. My compile, test, edit cycle is now driven mostly by the Acme editor which makes it easy for me to script connecting to remote systems, issue builds, find failures, and jump to the line of code where things break while I'm working. I haven't found a way to go faster than this. Perhaps VS Code could replace some of this, but I just don't have the time (or perhaps the gumption) to give it a try honestly. Maybe I'm just having too much fun...
• Mikeb85 5y ago
  2021 and Emacs still my preferred editor (and I'm young enough, in my 30's). Yes it requires a bit more setup (not much more however, VSC also misses functionality out of the box). However that setup is saved forever, across machines in the form of your .emacs file, so whatever changes you make to make it personal stay with you. And it's really not much more difficult to setup, Emacs lisp is more intuitive than JSON files and as a programming language, it's pretty easy to understand that you invoke a function and then just pass it parameters, and that's about all you need to understand about it to set up the editor anyway. But there's literally nothing I don't have with Emacs that other editors provide. I have code completion in a bunch of languages (that pops up, with documentation pop-ups), linting, snippets, a project tree preview, project awareness, etc...
  • deleted 5y ago
    [deleted]
  • criddell 5y ago
    > But there's literally nothing I don't have with Emacs that other editors provide. Some IDEs that can semi-compile the code (to something like an AST) can provide a lot more support for refactoring correctly.
    • Mikeb85 5y ago
      > Some IDEs that can semi-compile the code (to something like an AST) can provide a lot more support for refactoring correctly. Plenty of Emacs plugins invoke a compiler, language server, whatever to get information about the code. That isn't a feature unique to IDEs.
      • ReleaseCandidat 5y ago
        >Plenty of Emacs plugins invoke a compiler, language server, whatever to get information about the code. Yes, but Emacs (at least the LSP-modes of the languages I use) doesn't offer the same refactorings and code fixes like the same LSPs do with e.g. Code. Treesitter doesn't work with many languages, so syntax highlighting is also lacking for many languages.
• Kessler83 5y ago
  Emacs is like Earth. You can't claim to "learn it" or "master it," but it's still the best place to live. Some other editor is more popular now, and in five years, something else will be more popular than that. Meanwhile, Emacs will continue to grow, fascinating new users and developers. Simply put, (eq 'new 'best) doesn't evaluate to true. Knowing your way around Emacs says something about you as a programmer or computer user. Like you are clearly curious, willing to learn, know some Lisp, read documentation and recognize possibilities and depth when you encounter them. Knowing editor XXXXXX usually says nothing.
• sleibrock 5y ago
  I have worked at a number of jobs where it sometimes required me to use coding. I was not treated like a programmer ever. I was given very old hardware and expected to do my work. The worst computer I had was a Dell machine which had an i3 CPU and 4GB of RAM. Opening VS Code on this machine brought it to it's knees. I solved this issue by simply using Emacs instead. It uses far less memory, didn't cripple my system, and it is after all my preferred text editing environment for the last few years. I eventually got fed up with Windows bluescreens that I switched to Linux, and then I spent more time fixing other people's older Windows machines than doing my tasks. Emacs has me sucked in and I don't see myself going anywhere else. Now I'm using Emacs on another old Dell with Linux in another workplace, and it's fantastic to use as always.
• didibus 5y ago
  As someone who picked up Emacs about 3 years ago, and now finds it to be my favorite editor, I think the only issue with Emacs is performance on large files and stability of builds on Windows.
• natded 5y ago
  Not possible until they simply suck it up and pander to plebs. I can have a development environment setup in VSCode in under 5-10 minutes in most cases; you cannot even begin to understand Emacs configuration (let alone what you need to google). You need to go heavy into the language itself.
• PaulHoule 5y ago
  I used to be an emacs partisan, but line continuation characters killed it for me. With vi I can cut and paste into other applications on the desktop, with emacs I can't. I'm not going to accept the "just customize it" argument because if you do any administration at all you will sometimes log into a machine that you've never seen before. Sometimes you're going to log into a machine that is damaged. In that case you should be facile with whatever editor is already installed on the machine.
  • CRConrad 5y ago
    > ...cut and paste into other applications on the desktop, with emacs I can't. You can't?!? Inconceivable! Well, no, not quite -- I think I know what that word means -- but pretty darn incredible.
  • philsnow 5y ago
    Emacs doesn't lend itself well to running on machines you've never logged into before, or ephemeral machines/containers/etc. It's not a tiny sleek thing that you can start anywhere and have the same experience (that's nano or vi), but if you let your local Emacs eldritch horror reach out with its noodly appendage to whatever you're trying to edit, you'll have a much better experience.
• xedrac 5y ago
  I've used Emacs for about 5 years now, exclusively in Evil mode. One of my biggest complaints is that my big complex configuration setup seems to break every time I migrate to a new version of Emacs, or a new computer. This last time, I had to install VS code to get my work done quickly because I didn't have time to mess around with my configuration (yet again). It was surprisingly easy to get up and going on vscode. If it wasn't based on Electron, I just might consider sticking with it. Tweaking Emacs consumes a lot of time and seems to never end.
  • natded 5y ago
    The speed to 'first development environment' (lol) is a day and night difference between VSC and Emacs. VSC is faster to setup by several orders of magnitude (even if you know Emacs). Overall I believe you can get the same functionality, if less customizable, in VSC. I can't remember the last time by VSC configuration broke. I guess there isn't much to break in it.
  • hhnever 5y ago
    Have you tried any package manager tool that support taking a snapshot of your current whole setup (i.e. all the exact package version you are using)? Then on your new environment, it can be restored by the snapshot you saved before. Here is one I'm using https://github.com/raxod502/straight.el https://github.com/raxod502/straight.el (it works for me except the overwhelming document).
• TacticalCoder 5y ago
  If anything I see more love for Emacs over the years, not less. From Spacemacs to DoomEmacs to all the vim users switching to Emacs+evil-mode. There's LSP support since a while too. The Emacs ecosystem is alive and very well. It's in much better shape than it used to be. I used to live inside JetBrains' IntelliJ IDE, starting at IntelliJ version 4 (yup, I'm that old) and I'd probably use IntelliJ again if I was forced to work in a nonsensical Java codebase, full of boilerplate, impossible to navigate because it became a gigantic mess of spaghetti code. But that is my vision of hell. Emacs is something else. My custom config is about 3 000 lines of elisp code, written over the years. About anything I want Emacs to do, I can have it do it. Dunno, last thing I did was configure my 3-ways merge/diff environment: didn't like the default, didn't like the layout, didn't like the colors. Dived into some elisp code and I changed the layout to better match my very wide screen. Another quick hack: when asking for the list of recent buffers/files opened, I wanted, for those in version control, to see how many commits they had (to quickly find hot spots)... Some elisp code to modify "counsel", one shell script. Boom, done. I've done that years ago. Still working flawlessly. I've written a plug-in for IntelliJ back in the days. It's horrible. Also if we compare Emacs to IDEs, it's the most lightweight, and by very far. It was "Eight Megabytes And Constantly Swapping" and it was funny joke in the 90s but today 8 MB fits in the L1 cache or so. It's not swapping anymore (even if it's a bit more than 8 MB, granted). I'm using the native-comp branch of Emacs since it came out and stuff like burntsushi's ripgrep directly integrated in Emacs. It is not just a bit fast, but incredibly fast. Sure there are gotchas. You have to dig a bit into elisp to fix the usual suspects (like long lines making it slow: it's all configurable). But you're in control of absolutely everything. You have the source code, use it when you need it. Now I know some are using Emacs with the default setup and the default keybindings and without knowing / using any elisp. I'm no elisp guru but I think Emacs only begins to show its power once you being to use elisp to tailor Emacs to your way of working. That's the thing: you adapt Emacs to your way of doing things, not the other way around. I don't think there's any need to "make it popular again". It is popular enough and it is thriving.
• didibus 5y ago
  I love Emacs, but you need to be a retro minded programmer to enjoy it, that means you have to prefer code as your user interface, because in Emacs, code is the main UX, you're basically living inside a running Lisp command shell. Now honestly, I don't think it needs to become more popular, I think it just needs to continue to attract enough people that are smart enough to work on future versions and maintain the popular extensions, and that's all.
• adamc 5y ago
  A number of years ago, I reported a problem with its default Python mode and the way it automatically indents things. I got a response, which confirmed it was a problem. Then nothing happened and the report was eventually closed. For me, that was representative of several other issues I had encountered over the years. It's a great tool, but it is 1) old and sometimes baroque ("make-frame" comes to mind), 2) so large, even if you consider just the built-in functionality, that they seem to have problems keeping everything up to snuff. I am starting to move to Visual Studio Code. That's a painful shift, because I wrote lots of customizations in emacs, but, on the other hand, it has much better tools for many modern things I need to deal with (AWS, for example). I love emacs, but it needs a replacement -- something with the same basic architecture, but more modern concepts of how editors work and maybe an extension language easier to get buy-in for than emacs lisp. I had hopes for Atom, but... that looks pretty dead.
• davidw 5y ago
  I have been a happy Emacs user for 25 years. Still gets the job done and is quite flexible with whatever code I'm working with, and hackable if I need to make it do things differently.
• bachmeier 5y ago
  Emacs is not just for programming. Given the popularity of other uses (org-mode being the obvious big example) it's likely that text editing is the bigger potential market than programming. There's a market for a customizable text editor. Look at what non-programmers are doing with Obsidian. The outdated defaults Emacs uses kills off their chances of getting into that market. Weird default shortcuts for no reason, a block cursor by default, strange terminology in the documentation, excessive keystrokes in the keyboard shortcuts (C-x C-s to save rather than C-s and C-f to search), and the list goes on. When someone gets to the point of customizing, they're happy with Emacs, but Emacs does everything it can to run them off before they get there. Another thing they need to do is make sure they have the best markdown mode in the default install, complete with Pandoc integration. As good as it is, org-mode is not what most people are looking for when they are writing a text document. > Yes, make Emacs appealing and user friendly. But don't forget that a masterful tool in the end requires mastery, which can't come for free. That's true, but why add all the unnecessary baggage for new users? Just make the editor function like any new user expects and let the customization options turn them into passionate users.
  • MonkeyClub 5y ago
    > a block cursor by default Hands off the block cursor, it's very helpful with astigmatism.
    • bachmeier 5y ago
      Nothing against the block cursor as long as it's not on by default. I'm having trouble thinking of other text editors that use it as the default.
      • worksonmine 5y ago
        The block cursor serves a very specific purpose. Since you can insert either before or after the cursor a block makes perfect sense. Especially as a beginner being used to normal text editing, but even now after years of using it my reasoning is still "do I need it before or after the cursor" and looking at the block. What's your reason for not wanting it by default?
• steelframe 5y ago
  At the recommendation of an EE professor, I adopted EMACS as an undergraduate in the first few years of the 3rd millennium. I stuck with it for about 18 years, including stumbling through a handful of custom elisp scripts to get some stuff done that I wanted. With the advent of VMs in data centers, I found that constantly installing EMACS started to become a real chore, and vi was just always present in base images. Also, always needing to remap caps lock and left ctrl was obnoxious, especially as I moved between Linux, Windows, and MacOS environments. So last year I bit the bullet and went fully into vi. First I did some research into the scriptability of the editor, and upon learning that I could hook events via autocmd that call into custom Python code, that was it for me. I wasn't interested at all in struggling to figure out some arcane (to me) elisp invocation just to do some simple text manipulation, when I already knew Python well enough to just get done what I wanted with minimal trial-and-error. Plus the wealth of libraries available from pip and Vundle pretty much gives me all the extensibility and integration with other toolsets I could possibly want. I spent some time practicing the key combinations for stuff I would effortlessly "just do" in EMACS: split window, jump to the bottom window in the frame, open a buffer, find text, highlight and copy, jump back to the other frame, record macro and run it 12 times, yank words/lines, re-indent region, etc. Aside from muscle memory, there really wasn't anything keeping me with EMACS any more. I still am not quite as proficient in vi as I was in EMACS, but at the same time my career has moved away from 100% coding to more a mix of emails, documents, and occasionally some code, so maybe that has something to do with my departure from the EMACS world. I care more about the hassle of having to install EMACS in various environments I jump into as I'm working with nodes in the data center than I do about my level of comfort and proficiency in EMACS.
• vzaliva 5y ago
  Emacs distributions I think is a good way to make it more popular. Out-of-box emacs install is very dry and unappealing. There are many packages which could be installed to make it much more modern and user-friendly. Emacs distributions which pack emacs with a list of packages and default customizations is the right direction. I've seen many new emacs users who started using spacemacs but would probably be put off by learning curve of standard bare-bones emacs.
• lgrialn 5y ago
  I fully expected there would be a fair amount of discussion of RSI here.
• cjauvin 5y ago
  I have realized recently that a value that is gaining a lot of importance for me is the stability of my cognitive investments, in terms of tooling, across a time frame that goes beyond my "current project", and more into the "my entire career" territory. In that sense, I feel more and more that the choice of learning and owning Emacs, more than 20 years ago, while in school, has paid off tremendously, in the sense that it has always constituted a solid and consistent backbone from which I can always start a new project, no matter what the context is (corporate or personal). I feel this would have been harder to achieve with a tool which is asking me to update it every 3 days, and which periodically introduce important paradigm changes forcing me to reconsider the way I work. In short, I value Emacs' stability and consistency across time and tech fashions more than anything else, as I grow older.
  • olivertaylor 5y ago
    This is the reason I left the whole app ecosystem. Apps are cool, and sometimes really great, but there’s no sense of permanence, no guarantee that your data will survive for long, that the app will be maintained, or that future devices will be able to run the app or access the data.
    • CRConrad 5y ago
      > This is the reason I left the whole app ecosystem. How... Uh, how do you use computers then? Isn't everything we do with them in some way through "an app"?
      • akho 5y ago
        Few of us would call Emacs an “app”. I’m pretty sure they are referring to mobile/Web stuff. You do have to be very careful there…
        • CRConrad 5y ago
          Yeah, I still use the boomer vocabulary: there is system software, and application software. The first category is called "operating system", and everything that runs on top of it is an "application". And outside of the old quip ("Great OS, shame about the editor") Emacs is AFAIK not an operating system but runs on top of one, so it's an application. Lazy young whippersnappers should come up with their own damn terms for new concepts in stead of just trying to co-opt and redefine existing ones.
• earth_walker 5y ago
  Here's the major benefit of investing long-term into emacs. Not only do I have virtually the same, infinitely configurable interface for coding in any language, I also have that interface for most things I need to do in my workday. On top of coding in my day-to-day I: - manage my task lists - manage clients and projects - keep a daily journal and other notes - draft documents and create templates - search through or replace in multiple documents - navigate directories and manage files - do quick calculations and tables - and much more All using the same interface, without having to reach for a mouse or switch to a different program. The amount of cognitive load and context switching this reduces is great. The only other tool I use that is as flexible is the web browser, but it's nowhere near as consistent. Of course it's emacs, so if I chose to I could also manage emails, newslists, blogposts, pong, etc. etc. If I'm playing with a language that is much better served by an IDE or vscode, then I can always use it for that language. However I find that a) those features that made me want to switch weren't worth losing the other powers and I eventually end up back in emacs; and b) often the language's emacs package will eventually end up with that feature anyway. It is absolutely worth the investment. No, you're not going see this benefit in the first month of learning it. It'll be incremental over years of using it. As far as configuration goes - Yes, you can spend lots of time in configuration, just like new linux users tend to spend years distrohopping. But it's not necessary. I suggest that if you learn vanilla emacs first, you'll figure out which keybindings you really need to change later on. My configuration has been stable for years, and the only time I need to edit it is if I've added configuration for a new package. I don't use overlays like evil or doom, so perhaps this provides a bit more stability, I don't know.
• finder83 5y ago
  I use Emacs (with Evil) daily, and despite having tried to move to other editors I'm locked into Emacs. Not so much because of the functionality of Emacs itself but because of plugins... First, Emacs has the best Vim compatibility I've seen outside of Vim itself. Visual Studio is probably "good enough" for me on this with the vim plugin, but that 5% difference in compatibility makes a difference in practice. But the largest reason I can't get away from Emacs is Ivy/Counsel. Being able to fuzzy search on the current file or entire project, see results, jump around to each one to see context, make changes to the results in an occur buffer to selectively mass edit search results...all of that I just haven't found a replacement for. Search/replace just doesn't cut it. So effectively if I move to another editor, my code navigation time increases by 5-10x. Things like better autocomplete might fill that gap, but just even understanding how things go together is so much more difficult when you're fighting with your editor. Add on other things like org-roam, buffer fuzzy searching in Ivy, fasd tie-in, the customization options, etc, and Emacs is just an amazing experience. There are definitely things I would change, like inline debugging (which I use VS Code for instead), setting up languages and autocomplete, etc. Getting things just right takes a long time for a new language.
  • skulk 5y ago
    The diversity in the emacs ecosystem has a hand in this I think. There are so many different ways to switch buffers: vanilla, Ido, Helm, Ivy, and all of the other ones I haven't heard about. This kind of diversity is unseen in other consolidated, centrally managed software ecosystems.
    • kristjansson 5y ago
      And those aren't just ways to switch buffers - they're options on a 'select among choices' dimension that's totally orthogonal to 'things that generate choices to select'. List of buffers, list of commands, list of files in a project ... can be presented, narrowed, and selected in an interface chosen by the user
  • rement 5y ago
    Nvim has some plugins and features that do some of the things you might be interested in. Telescope[0][1] which is a fuzzy finder for anything you can think of (files, symbols, color themes, etc.[2]). The LSP and Treesitter stuff in nvim 0.5+ is also pretty cool. If you want to just try it without much work the Lunarvim[3] project comes with sane defaults and included plugins (including Telescope). Lua as the default configuration language makes things simple to configure as well. Having said all that...if someone told me [insert-text-editor] had everything I would want I would probably check it out and go home to vim (but I do enjoy learning about new stuff and features). [0] https://github.com/nvim-telescope/telescope.nvim https://github.com/nvim-telescope/telescope.nvim [1] https://www.youtube.com/watch?v=65AVwHZflsU https://www.youtube.com/watch?v=65AVwHZflsU -- demo video [2] https://github.com/nvim-telescope/telescope.nvim#vim-pickers https://github.com/nvim-telescope/telescope.nvim#vim-pickers [3] https://www.lunarvim.org/ https://www.lunarvim.org/
• User23 5y ago
  Ignore the hater's comments. Emacs is Lindy[1], will be around for another 40+ years, and no amount of ankle-biting will change that. Having used it off and on for a couple decades, I can say with confidence that the Emacs community and ecosystem has never been stronger. And thanks to the LSP, it's comparable in IDE features to other LSP capable editors. With the new in version 28 type-inferencing JIT compiler[2], performance has also never been better. Emacs outshines all other editors in two major respects: discoverability and extensibility. These are two sides of the same coin. When I say discoverability, I mean how the editor actually functions, not just reminders for what the keybinds are. The internal calls can be instrumented, advised, and even rewritten. And this ties into extensibility. In other editors writing an extension is a full blown project. Let's say you identify a need while you're doing your real work. In most editors you now have to create a new plugin project and set up a bunch of boiler plate before you can even get started. By then I've already discovered what I need to do and hacked a solution in the scratch buffer without getting dropped out of my flow for my real work. There's no denying that Emacs has its warts and that Elisp has a lot of historical baggage. Those who don't grok the Lisp approach to interactive development will never be able to understand why even an admittedly mediocre Lisp is a more frictionless development experience than anything they've ever used. [1] https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect [2] https://akrl.sdf.org/gccemacs.html#orge596749 https://akrl.sdf.org/gccemacs.html#orge596749
• anonuser123456 5y ago
  I’ve been an emacs user for 10 years. Before that, vi for another 10. This year I switched to VSCode and I will probably not go back. I like emacs, but the modes I depend on are just too brittle, and there is no easy way to discover that your old favorite mode for some particular feature set has been surpassed by a new one in popularity. VS Code plug-in search gives you ranked options. Also, there is something to be said for having everyone on your team / company on the same editor; you get economies of scale w.r.t. setting and configurations. As someone that personally invests in tooling, it’s nice to then be able to scale that tooling out to 50 people and have everyone get the benefits. I can’t do that with emacs, because the learning curve is too steep. But I’ve been able to switch dozens of people with VSCode.
  • edgyquant 5y ago
    I was a vi user for a decade also and decided to try vscode and never looked back. I’m really not sure what it is about it but i just don’t fight with it. Since then I’ve also switched to PyCharm for python editing
• dang 5y ago
  Discussed at the time (of the article): Making Emacs Popular Again - https://news.ycombinator.com/item?id=23107123 https://news.ycombinator.com/item?id=23107123 - May 2020 (761 comments)
• cjv 5y ago
  I'm curious to know what people think about elisp as a extension language. Would Emacs be better if everything was implemented in elisp including the core data structures (assuming elisp was very fast)? Do people suffer from lack of static typing?
  • b3morales 5y ago
    Elisp is nowhere near perfect, but it's fast enough in general. I recently wrote an indent function for a private DSL; it looks like a big slow mess, but when I run it on a code file, it does its job with no noticeable lag. You can write slow code in any language, of course.
• randomstring 5y ago
  I've been using emacs as my primary editor since 1989. It has for that entire time been a PITA to configure. My first customization was to map backspace to ^H and map the insert key to 'nil. I used to dedicate a couple days every January to investigate new emacs tools. Read about the latest features or new modes, often from my org-mode TODO list where I bookmarked them. I have learned to never update emacs mid-project as I've on multiple occasions shattered my emacs config updating versions or moving to a new distros. MacOS brew install vs .dmg install? Aquaemacs? DoomEmacs? Oh, hello the malpa repo URL changed and is https only now. "eldoc" error wrong-type-argument stringp number-or-marker-p Googling that doesn't get you anywhere. VSCode has a healthy extension marketplace, something emacs should adopt. elisp is dead. Not because it is dead, or deserves to be dead, but because everyone "believes" it dead. Same goes for Perl. I love emacs, it has been a rock my entire programming life, but it's a time suck to configure. I know there are some who have created a Sistine Chapel in their .emacs.d, and I'm jealous. There's a fine balance between spending time and effort optimizing and sharpening your tools and emacs is deep on the wrong side of the line for me. I don't want emacs to ever die. But come on, if you're losing to vim in popularity, you are already dead.
  • akagr 5y ago
    > elisp is dead I’m not sure it was ever alive to begin with. Not in the classical sense. I mean, I don’t think elisp ever got good (or any) use outside of emacs configuration and extension. There weren’t any popular web frameworks, numerical libraries etc. written in elisp. Inside its target space, though, it seems as vibrant as ever. New, helpful packages keep appearing that are written in elisp. For better or worse, the extension ecosystem is not nearly as fragmented as some other editors. That’s not to say that elisp doesn’t need serious improvements, though. Making it natively multi threaded alone will advance the story quite a bit imo.
  • rbanffy 5y ago
    > VSCode has a healthy extension marketplace, something emacs should adopt. What’s wrong with MELPA?
    • tarboreus 5y ago
• AtNightWeCode 5y ago
  Have not used Emacs since I coded things in Lisp on SPARC machines in the last century. This got me curious though. Will try Emacs again just for fun.
• rawoke083600 5y ago
  Any "recently-beginner-Emacs" users that could share a good tutorial or "the one" tutorial that made things click or made them push through ? Side Note. I recently "invested" my time in moving to i3 and the first week was hard as hell, but now i can't imagine my daily linux life without i3. Conclusion: As "computer professional" it always pays off to invest in learning your daily-tools properly - Advise from a very wise ex-boss !
• bondolo 5y ago
  Editor fetishism should have died in the last millennium.
  • iLemming 5y ago
    Ehm. I think it's natural, and there's nothing wrong with that. I'm not a musician but I think, for example, guitar players do fetishize their instruments and have their favorites, no?
• shaoner 5y ago
  I've been using Emacs for 15y, I can't replace it. Emacs-server is just amazing for me. I truly believe that its weakness is elisp, it's not hard but at the same time it's not a language you want to learn or spend time with, so of course that means less packages, less support and less interest in customizing it well. Other than that, I would be quite happy to see a modern version, with support for another scripting language and maybe dropping all these UI features, like menubar, toolbar etc. If we acknowledge there's a learning curve, the UI buttons are non essential. VSC & others are probably better at this.
• hvasilev 5y ago
  I fell for the "text editor only" meme 8 years ago. I'm actively a vim user that uses tons of plugins just to be able to do simple things that IDEs do by default. I would not recommend it to anyone. I work primarily with embedded systems (ST and NXP MCUs). Not working with the respective IDEs that have been specifically designed for this type of work and using a text editor instead (of any type) would be objectively a bad choice. There is just so much value in being able to visually configure pins, peripherals, clocks, etc. that just the text editor makes no sense. Also the debugging experience is probably order of magnitude better. What you can do and what does make sense is vim emulation inside of the IDE. It is not perfect, but it is what it is. There is A LOT of ideology in the software world. DO NOT FALL for it. Take things at face value. Be a pragmatic, not an ideologue.
• deleted 5y ago
  [deleted]
• Bostonian 5y ago
  I'm an experienced Emacs user but not an advanced one. What I like is the ability to have code in one or more buffers and a shell (CMD on Windows, bash on Linux) in another buffer. In that buffer I compile with `make foo` and see the output there.
• tonyfader 5y ago
  please, no.
• amosj 5y ago
  Emacs groks my soul. I can't defend it's flaws. But if I'm reborn a developer in a thousand years I sure hope it will still be around. Otherwise I'd rather be a shrimp or a dolphin or something (I hope those will be around too)
• SNosTrAnDbLe 5y ago
  I have stopped using emacs from the last 5 years since I had problems with its key bindings. My left little finger ended up paying the price as that is what I use for control key. I still miss org-mode which I used for more than 10 years. It is one huge reason why I kept coming back to emacs even after all the hurt. From then on, I used sublime and now vscode to do text editing and an IDE like IntelliJ for development. My left little finger has gotten a lot better.
  • therealcamino 5y ago
    I hear you. The first thing I do on any new computer is remap the Caps Lock to be Control, for exactly that reason. It helps a lot.
  • guantanamo_bob 5y ago
    Try spacemacs, much more comfortable.
• iLemming 5y ago
  I think the only way to make Emacs popular is to get more users. And in any of the over six thousand human languages in use today: "Emacs user" typically means "a programmer". Emacs desperately needs more programmers. Unfortunately, many of the core Emacs developers are also FSF advocates. Some of them have very radical and uncompromising views. It sometimes feels like they have little understanding of the real world and the software industry in general, and they live in the 16th century equivalent of the computing world. I mean, many of us (software developers) are very sympathetic to the cause and the idea of liberating all software, but sometimes it just gets too crazy. As if someone tried saving the world by harassing palm oil plantation workers in Indonesia: "Why don't you try planting cedar trees instead?". Vilifying and fighting the evil in the industry is right; punishing everyone indiscriminately - is not. One of the latest examples: a question about LSP server implementation for Emacs Lisp - the verdict of the people in charge? Nope, we shouldn't do it because: "it would allow editing Emacs Lisp in non-free programs like VSCode". Seriously? IMO, it's not just a simple non-sense, it actually sounds like borderline narcissistic schitzo thinking. Emacs codebase needs to adopt the ubiquitous and familiar model of issues and pull requests instead of clinging to the outdated way of email threads and patches. That's what made Neovim popular. That's how VSCode achieved in just five years, what was like twenty for Emacs. That's why the most innovation in Emacs happens today outside of its core. Today GitHub, GitLab, and other Git forges have so much Emacs Lisp - it's probably the most widely used Lisp in the industry (maybe even comparable to Clojure and Common Lisp). And guess what? Authors and maintainers of those awesome libs and packages not sending patches over email. I don't think Emacs is going to fade away anytime soon. But the strategic mistakes made by the core decision-makers have done irredeemable damage, and Emacs now doomed to play catch-up.
  • CRConrad 5y ago
    > Nope, we shouldn't do it because: "it would allow editing Emacs Lisp in non-free programs like VSCode". Seriously? Emacs supports copy-paste, doesn't it? So you can already edit Emacs Lisp in non-free programs. Just paste it in from any JetBrains editor, or from MS Word for that matter.
• nobody9999 5y ago
  I read through the comments here a couple hours ago and heard all the same arguments that come up whenever folks talk about emacs vs. other editors|IDEs|platforms|OS's. As such, I didn't feel the need to add my own comment to the fray. But as I was scrolling through the front page, the title of the article struck a chord. I'd say that emacs was never popular. It is (and always was) a fairly niche product used by those who found something about it compelling. Even "back in the day" emacs usage was dwarfed by vi (vim didn't exist), notepad, Wordstar, WordPerfect and even ED/EDT[1]. Full disclosure: I am a long-time emacs user (25+ years, preceded by using the Epsilon Programmer's Editor[0] -- a commercial emacs work-alike -- for 5+ years). [0] https://en.wikipedia.org/wiki/Epsilon_(text_editor) https://en.wikipedia.org/wiki/Epsilon_(text_editor) [1] https://en.wikipedia.org/wiki/EDT_(Digital) https://en.wikipedia.org/wiki/EDT_(Digital)
• todd8 5y ago
  I've used full Emacs and Emacs style editors (mg, jove, epsilon) for over 40 years and programmed in LISP for longer than that. In the 1990's it was evident that Emacs was in decline. For a couple of years, I used Vi because IBM's lawyers were afraid of the GPL; during that time I found Vi to be a superior text editor than Emacs. Sometime in the late 80's, Emacs and the GPL were accepted by IBM's planners, and I switched back to Emacs. Quite a few of the AIX kernel developers did end up using Emacs, even though Vi had its advantages as a text editor. It was the customizability of Emacs and the ecosystem of high quality packages that drew me back to Emacs. (For example, a developer on my team wrote the tower of Hanoi command. Try it out: M-x hanoi). Emacs became a general purpose tool for interfacing with your system. With Emacs, I didn't need a graphical terminal to work with multiple windows, I didn't need Norton Commander to have a powerful, portable interface to directory management. It has incredible outliner, mode for LaTeX, interface to git, etc., etc. My point is that it wasn't the text editing (Vi handled that better), it was everything else, and that everything else was enabled by Stallman's brilliant insight that the editor should be built around a powerful interpreted language, LISP. LISP was key to the success of Emacs. In the 1980's, people were excited about LISP; by the 1990's the excitement was wearing off. The LISP Machine companies weren't commercial successes. While some LISP compiler/interpreters performed well, Emacs Lisp was simply adequate. In CS programs, Scheme was being taught instead of the more fully featured LISP--Scheme has a simpler tighter core of fundamental features and consequently was a better choice for the ubiquitous undergrad Programming Language smorgasbord courses. I needed an embedded interpreter to be a key part of a distributed network of servers I was designing. LISP was my choice, but my companies own, very experienced, developers rebelled. Smalltalk, Prolog, and even building our own C-based language interpreter were all viewed as more acceptable than LISP. The way to make Emacs more popular isn't to persuade people that they want a customizable editor that requires a great deal of LISP expertise. That just won't happen. Pick a language from the one of the top 15 languages and allow Emacs customizations to be developed in one of these languages. Here's one measure of the 15 most popular languages[1]: Python, Java, Javascript, C#, C/C++, PHP, R, Objective-C, Swift, Typescript, Kotlin, Matlab, Go, VBA, Rust. Out of the 15 languages listed above, many can be disqualified for obvious reasons: R and Matlab are not general purpose enough, Rust is far from interpreted and has a slow compiler, and so on. In my opinion, Emacs would be more popular if its core supported Python or Javascript or even Go (say running in a separately compiled process that interacted with the Emacs server via IPC). I'm not a Javascript person, but Javascript is likely the best solution; I would gladly take the time to learn how to use it for Emacs configuration and customization. If Emacs was customizable in Javascript, there would be an army of developers working with it. [1] https://pypl.github.io/PYPL.html https://pypl.github.io/PYPL.html
• hosh 5y ago
  I didn't start using emacs until (1) hardware became fast enough to run evil-mode with low keypress latency (because vim uses key sequences rather than chords and I type fast), and (2) Spacemacs. I switched to Spacemacs before there were a neovim, and if it weren't for spacemacs, I would have ended up with neovim instead. I have not had time to really dig into the code and customize my editor. I installed Spacemacs, some layers, and know just enough to keep the things I am used to there (such as layouts), and that's pretty much it. I really enjoy how Spacemacs organized things, and it has made it much easier to learn. I still typically use vim for quick-editing config files on remote systems.
  • guantanamo_bob 5y ago
    I recently switched from emacs to spacemacs. I love the key bindings, but the Emacs GUI with spacemacs is so slow it’s unusable, keeps my laptop running burning full speed.
    • hosh 5y ago
      That sucks. I use spacemacs remotely on a terminal with mosh and tmux, so I don’t notice. But back in ‘10, evil mode wasn’t usable for me on the terminal. I imagine spacemacs on 2010 era hardware would suck, let alone GUI. I wonder if the new chips like the M1 would make a difference.
• hnrj95 5y ago
  it’s worth mentioning that there’s been great work wrt emacs and its packages very recently. it seems somewhat revitalized, i think
• anamax 5y ago
  When I started using Emacs, it was still written in teco. (I did use raw teco once.) In all that time, I've NEVER customized or configured it. That was a huge advantage when I was working very closely with other people - they could use my Emacs session and (mostly) work and I could grab theirs and always work. "Never" is not quite true. I borrowed someone's customizations for a year or two, but they weren't worth the hassle to move them to a new machine so I went back to "no customization." Every few years, I ask "wouldn't it be nice if Emacs did {something}". I then find that someone implemented said something, and it's in the released version.
• musicale 5y ago
  > We need to figure out why VSC is so popular, and then fill in the areas that Emacs is missing Great support and built-in IDE for Microsoft platforms. And the fact that it isn't a relic of the 1980s (well, 1970s in terms of text UI, and perhaps 1990s in terms of GUI.) Also (horrifyingly enough), VSC can be more responsive.
• rolandog 5y ago
  As a 'new' user (less than a year, and still customizing my init file), I can say that I started using Emacs because of org-mode and or-roam. As a chemical engineer, my use case is that of being a researcher, programmer, and tinkerer. So, the initial appeal was that of having the ability to version-control, pre-process, and have 'reproducible builds' of my articles or documents (if I add more data, I wanted to be able to update the numbers in the article). And, most importantly... I was drawn in by the capability of using org-roam to try out the zettelkasten methodology (even more so now that there's org-cite). My journey has been to first slowly learn Emacs, then org-mode, and finally I'm starting to learn org-roam, and to learn make my own templates for my zettelkasten implementation. Before all of this, I had tried using Vimwiki and Taskwarrior for productivity and knowledge administration, and I had also used PP and ABP as Markdown preprocessors with Pandoc for documents generation. I still prefer to use Jabref for reference management (mostly for looking up by DOI or ISBN, and pairing with the PDF and epub), but I might try to eventually learn a way to go do that with some of the bibliography managers on MELPA. For coding Python, specifically, I'm still fond of Spyder. But I also intend to transition and try out ways to achieve the same things that allow me to produce high-quality code (with rich documentation). I plan to re-learn modern FORTRAN on Emacs, however. Anyhow, my experience of Emacs onboarding has been that of slowly learning what can or can't be done by searching for random snippets of init file configurations, and reading the Emacs and org-mode user manual. Also, by watching System Crafters' videos, as well as videos from other very talented coders and researchers that have shown how to use org-babel to create reproducible research. Finally, I wanted to add that one of the best-selling points for org-mode and Emacs, is the ability to do so many awesome things just from plain text files, with very low memory and disk footprint (in stark contrast to VSC). One thing I forgot to add is that I'm thankful for all the hard work that has been done in creating a cool ecosystem of software that has resulted from developers scratching their own itch. I have donated once, and will donate again... but I also intend to contribute and help keep free software alive.
• coldtea 5y ago
  Judging from the discussion in the Emacs lists, they are not going to go anywhere. This needs a few people that (a) want to do it, (b) have a specific vision of what to do (as in, they don't fish for random suggestions), (c) have the power to do it (even if others disagree). This is totally feasible in, e.g. VS Code. In Emacs? Not so much... Instead, there's endless bikeshedding and "change by commitee" with momentum-killing vetoes...