21 ms·

The Emacs Lock-In Effect or the Emacs Sunk Cost Fallacy

• anyfoo 5y ago
  I'm in a similar boat as in the first quote: Have used emacs for decades, glad that I do, can't imagine switching... don't think I would recommend it to anyone new, unless they are really open about learning something entirely different. Emacs seems to be in the same position as LaTeX: Outdated paradigms that would probably need an entire redesign from the ground up to start "making sense" in the modern world. This starts with (nowadays) non-conformant shortcuts, includes window/buffer management (the terminology alone is archaic: panes are windows and windows are frames), and ends with elisp, which even Lisp programmers themselves rebuke. But such a do-over is impossible in both LaTeX and emacs, since that would also mean throwing all the thousands (ten thousands?) packages--and lots of core functionality--away. Stuff that has accumulated for many decades and that is the reason why we're sticking with it: Everything else feels very limited in comparison. And it's not just the "big" things. When I want to sort a few lines in a region and immediately discover that I can just call "sort-lines", because of course I can, I know that I'm not going to bother waiting for some other editor to catch up in all those little things. Admittedly, I haven't tried modern distributions like spacemacs and DOOM Emacs, but it's a bit hard for me to imagine that you won't need to come face to face with "emacsism" at some time.
  • CalChris 5y ago
    With respect to LaTeX, I only started to use it semi-recently in the cloud and I'd recommend it to anyone (but only in the cloud). I don't want to master an editor anymore. I want to get work done. Pretty much the same with LaTeX. When I want to improve something in a doc, I look it up and do that. When I go back to the doc later, I don't always remember what that magic meant. But that's ok, I'm writing a doc. I'm not trying to master the writing of a doc.
    • anyfoo 5y ago
      I don't want to deeply learn an editor myself anymore, too, but that being said I am still extremely glad that the past decades have made me proficient in emacs. The editor is just one of the most important tools for me.
    • cpach 5y ago
      Just out of curiosity, which editor do you use? Overleaf?
      • CalChris 5y ago
        Yes, Overleaf. I'd always had LaTeX envy but when faced with installation and configuration, I gave up again and again. Overleaf solved all that.
        • bkallus 5y ago
          In college we were required to typeset assignments in LaTeX for all the math classes past multivariable calculus. I started out with Overleaf, but switched to local compilation about a year in. It's much nicer to be able to write in my usual text editor and compile documents instantly. On Arch, all I had to do was install texlive-most. It includes every package I have ever needed to use. To compile a document, I just run 'pdflatex *.tex'. Sometimes bibtex too. If you're having trouble with setup and configuration, I recommend texlive.
        • andrepd 5y ago
          >installation and configuration On Linux, literally run the texlive installer script and install an editor like TexStudio if you'd like. That's it.
    • User23 5y ago
      Imagine a carpenter saying, "I don't want to master my tools, I just want to build things."
      • sokoloff 5y ago
        There’s mastering the use of your tools and there’s tinkering with the windings on the electric motor inside your tools. Emacs offers users both.
      • jrochkind1 5y ago
        How common is it for carpenters to make their own tools? I actually don't know!
        • PaulDavisThe1st 5y ago
          Did you write Emacs? Did I write Emacs?
        • AlanYx 5y ago
          For a lot of custom carpentry, it's pretty common for carpenters to make their own jigs to solve specific problems (e.g., if you need to use your router a bit like a thickness plane to mill down some object by a couple of millimetres along some axis so it fits somewhere, you probably want to build a jig first).
        • _moof 5y ago
          Pretty common, I think. I've made clamps and rove punches for instance, and I've been tempted to make drill bits. (But this is for wooden boatbuilding, which is its own uniquely crotchety corner of carpentry. Not unlike emacs...)
        • ARandomerDude 5y ago
          For most woodworkers, I'd say the analogy is closest to making "plugins" for existing tools. They require a little knowledge (which easily obtained on YouTube), and can greatly increase your ability to use the base tool. One example is a table saw sled, which helps you make clean, repeatable, 90º cuts. It's one of the most useful "plugins" you can have for your table saw, and relatively easy to make. Making the actual table saw, on the other hand, would be expensive and very difficult, and would require knowledge of many fields (metal working, electrical systems, etc.).
    • Ar-Curunir 5y ago
      The problem with LaTeX is that it isn't well-designed enough that you can just use it without thinking about the magic. When stuff is not up to scratch (image is placed incorrectly, spacing in your table is wrong, your diagram has an incorrect alignment, etc), the error messages suck, and you often need to figure out what the magic does to be able to fix the issue.
    • marcosdumay 5y ago
      The thing with LaTeX is that it's a full text-oriented programing language. What is great if you want to extend it, but a problem if you want to use it on any context not supported by the interpreter. So, if you don't want to create a PDF, it just sucks.
    • eulgro 5y ago
      > With respect to LaTeX, I only started to use it semi-recently in the cloud and I'd recommend it to anyone (but only in the cloud). $ latexmk -pdf main.tex How hard is that? The only thing Overleaf adds here is a button and a 10x compilation time overhead. > I don't always remember what that magic meant. Overleaf mostly won't help you here, unless I'm mistaken. I don't mean to be aggressive here, I just don't get the Overleaf hype. What's wrong with good old text editor + version control? I think I'll pass on the slow web app for now. At least they have Git integration so nobody is going to force me to use it.
      • remexre 5y ago
        How do you do package (version) management for LaTeX? There's more than a few documents I've come across that won't build on my system, giving often-indecipherable compilation errors. Overleaf at least ensures everyone involved is using the same environment without needing to ship a Docker container or the like, or try to pin down versions.
        • eulgro 5y ago
          I suppose it should be fairly portable, except for missing packages maybe. In my case I have literally every common package installed so that's not an issue. But LaTeX errors are a real pain, I'll admit that.
        • Filligree 5y ago
          Nix has a decent solution here, i.e. turn the document into a nix derivation. with import <nixpkgs> {}; pkgs.runCommand "cv.pdf" rec { src = ./cv.tex; bin = with pkgs.texlive; combine { inherit scheme-medium collection-latexrecommended collection-fontsextra moderncv etoolbox; }; buildInputs = [ bin ]; allowSubstitutes = false; } '' ln -s $src cv.tex latexmk -pdf cv.tex mkdir $out mv *pdf $out/ '' These days I'd probably use flakes to pin down the latex version.
      • moron4hire 5y ago
        Lol, that's not the command for making a LaTeX document. The command for making a LaTeX document fills a sheet for all the shit you have to install--half of which isn't correct on whatever documentation you're reading--and THEN you can `latexmk`. And I do mean you. I gave up after a solid week. I'll just make whatever I want in PowerPoint, save it to a PDF, and be done in 15 minutes. Yes, I said PowerPoint. Set you're slides to 8.5x11 and it became a typesetting program. I've started getting my coworkers to use it for such and they are absolutely delighted by the bump in design quality they are getting because they aren't fighting Word anymore.
    • lenkite 5y ago
      Use pandoc
  • 908B64B197 5y ago
    > But such a do-over is impossible in both LaTeX and emacs, since that would also mean throwing all the thousands (ten thousands?) packages--and lots of core functionality--away. For LaTeX a large part of the appeal is to get a template and be able to respect whatever arbitrary formatting requirements. Someone could build a layer on top of existing LaTeX to add a more modern language on top of it and have it expand to LaTeX.
  • grae_QED 5y ago
    Why redo something if it works? People are still using Fortran because it works well for certain applications. Just because its old doesn't mean its outdated. I could even argue that since Emacs hasn't been phased out (and still has a decent user base) that it does something that other text editors don't (or can't) do.
    • Jtsummers 5y ago
      Fortran has seen major changes over the 64 years it's been in use. I feel that Emacs Lisp has had a much slower evolution (though admittedly I've only used it for about 20 years, I can't comment on how much it changed prior to that). In particular, the biggest change I'm aware of with Emacs Lisp (the language) is that we now have lexically scoped variables. The biggest change to its implementation has been a push towards native compilation (much improved performance, I like it). The language has, otherwise, largely remained the same. In some regard, this can be seen as a consequence of having a decent base language. Where Fortran's original version became increasingly indecent as time went on, Emacs Lisp seems to have held up better thanks to a stronger foundation. That doesn't mean there isn't room for improvement. In particular, the things that (my opinion) are still missing from the language are: 1. A good concurrency model. CSP, actors, I don't care but it needs to exist. Paired with the native execution we're getting now, this would greatly improve the real and perceived performance of the system. 2. A real module system. I'm not talking about a package manager, but moving things into module scopes a la Common Lisp packages. The prefixed names for functions and variables is a hazard. Even if you leave every symbol exported by default so that you don't lose visibility to module internals it would be better than now. It would also open up a lot of opportunities like the potential to run multiple versions of the same package side-by-side.
      • BeetleB 5y ago
        > Fortran has seen major changes over the 64 years it's been in use. And yet most Fortran programmers reject/ignore those changes and stick to Fortran 77. When I was in academia, I couldn't find a single person writing Fortran code in anything newer than 77.
  • Koshkin 5y ago
    > entirely different Well not entirely - it's modeless, and some usual keybindings work as well (Home/End, etc.). The built-in tutorial is brief and to the point, it will get one started pretty quickly.
  • chipotle_coyote 5y ago
    > Admittedly, I haven't tried modern distributions like spacemacs and DOOM Emacs, but it's a bit hard for me to imagine that you won't need to come face to face with "emacsism" at some time. Speaking from the experience of someone who has repeatedly bounced off Emacs for going on two decades now, you absolutely will. :) > When I want to sort a few lines in a region and immediately discover that I can just call "sort-lines", because of course I can, I know that I'm not going to bother waiting for some other editor to catch up in all those little things. This sort of "little thing" is, perhaps ironically, why I keep going back to BBEdit, at least for my technical writing work: it has a whole lot of these little "multipurpose tool" commands for text manipulation -- and, because they're in old-school Mac menus, they're discoverable. Thinking about it, that's one of the main reasons I bounce off both Emacs and Vim: it's not that I can't figure out the basics or even the, er, intermediates; it's that so much of the advanced stuff is relatively opaque. I am sure that there is probably a command in both Emacs and Vim that equates to, for instance, "find all lines matching this regex that occur more than once in this document, delete them, and copy them to a new document" (a task which sounds like I am making it up, but I swear I have had to do on multiple occasions in my current role). But I am also sure that it is not as easy as selecting "Text > Process Duplicate Lines..." and checking "Delete duplicate lines", "Leaving one" and "Match using pattern".
    • anyfoo 5y ago
      Top of my head, I am pretty sure that I can do that with a "keyboard macro" involving list-matching-lines, and delete-matching-lines (that is literally what the commands are called). "Keyboard macro" by the way is a good and a bad name at once: It does not fully describe the vastly more powerful feature, as it is much more semantic than just repetition of keystrokes, but at its surface it looks like that and helps you get started. If anyone reading this hasn't used keyboard macros in emacs, try it out the next time you do something repetitive. It's amazing how it can simplify those tasks. "C-x (" to start defining one, "C-x )" to end it, "C-x e" to run it, which conveniently also ends definition if you want to use it right away. Of course you can do things like "M-5 C-x e" to run it 5 times. But I do get your point: Things are probably much less discoverable in emacs, unless you are relatively proficient in it already maybe. You need to switching into a "programmer" mind fairly quickly, while BBedit probably just lets you do powerful stuff through simple UI.
  • Cacti 5y ago
    There’s at least two ways you could keep the Emacs ecosystem while refreshing some of the other pieces (to build a new editor): - You could reimplement the Emacs LISP VM and change what some of the native editor types refer to (buffer, point, window, etc.) so that they are interpreted in a “modern” UI setting. Maybe add some new opcodes while you’re at it to handle things like threading. - You could fork emacs, strip out the display engine, and completely rewrite it (it’s notoriously complicated and probably not worth dealing with 50 years of legacy hacks). Either of these options would give you a reasonable chance of skipping over the inherent complexity of the system without having to ditch all of the ecosystem packages), though they’re both still pretty involved. A big part of the reason for this is you’d inherently end up losing some OS compatibility in the process, and maintaining compatibility is probably the biggest problem with making changes or updates to emacs. If you’re willing to ditch that burden, your options expand dramatically.
  • stouset 5y ago
    > And it's not just the "big" things. When I want to sort a few lines in a region and immediately discover that I can just call "sort-lines", because of course I can, I know that I'm not going to bother waiting for some other editor to catch up in all those little things. FWIW this is something most editors let you do trivially. With VS Code, select the lines you want to sort, press Cmd-Shift-P to bring up fuzzy command search, type "sort", press enter. Your selected lines are sorted. I think you might be surprised to find that all the major editors these days have most all of the little things you might want day-to-day covered. Of course the set of little things one cares about will differ from person to person and from the capabilities we've personally found the most use out of. It's hard to argue when that one thing you use every day isn't supported in some other editor, but the list of those is shrinking quicker than I suspect most people realize. There are a lot of people contributing to these tools and that plus not having to reinvent every wheel from scratch (and maintain that code on top) means that modern editors can cut into the lead time advantage of something like Emacs quicker than you might otherwise think.
    • neolog 5y ago
      I agree with what you say about IDEs, but Emacs' "advantage" over other text editors is that it is only superficially a text editor. It's really more of an operating system.
      • CRConrad 5y ago
        How does the old joke go -- "Now if Emacs only had a decent text editor, it would be a pretty decent OS."
        • mike97 5y ago
          Evil mode
    • viseztrance 5y ago
      I think you would still be surprised at how many things emacs can still do better like undo in region or even simple macros that find use even during simple text edits. Though ultimately feature per feature, I don't think emacs looks all that great, but the difference is that you can actually use a lot of what it has to offer whereas it's difficult to do so in more modern editors (with fuzzy matching and all).
  • bsder 5y ago
    As an emacs user, I would say that emacs really didn't have competition until VSCode and modern programming languages. For example, everybody was kind of 80-90% on syntax highlighting. Some editors and IDEs were a little better at one language than others, but most weren't that great and had all manner of weird edge cases. And, if you wrote a new language, good luck because you had to write a syntax highlighter for it in both emacs and vim to get traction. And then VSCode came along with the Language Server Protocol. Suddenly, you only needed to write a well-constrained plugin to get your syntax highlighting to about 80%. That was okay. But the modern languages learned from the failures of C and C++ and designed themselves to be parsed quickly and accurately. So, now your LSP syntax highlighting could go to roughly 99% accuracy on VSCode. And the highlighters were incremental. Suddenly there was a genuine advantage to using something other than emacs. And this is before we get to things like a debugger that works, etc. I've used all the IDE's, but VSCode is the first one to pry emacs from under my fingers. And for people who like to complain about VSCode and Electron bloat (a valid complaint), I'd like to point you to some of the old nicknames from the emacs vs vi religious wars (Eight Megabytes And Constantly Swapping springs to mind ...) Bloat simply isn't an argument for most people.
    • anyfoo 5y ago
      I agree that lsp is a necessity nowadays, and I was almost willing and close to give up emacs. And then emacs got proper lsp support (even in at least two forms, lip-mode and eglot), and now I'm happy.
    • lliamander 5y ago
      Is there a definitive Emacs key-binding plug-in for VSCode? I've tried several in the past and none seemed quite right. IntelliJ, on the other hand, has great support for emacs key-bindings.
    • Frondo 5y ago
      One other thing about VSCode being an Electron app -- it is by far the snappiest and most responsive and least bad memory-wise Electron app I've used. This isn't like Slack or Discord. It's like magic what they've built on Electron, one of these days I'll dig into the code to see how they did it.
  • impendia 5y ago
    What is your criticism of LaTeX? I am a research mathematician, and I and essentially all my colleagues are LaTeX users. To me it feels like the correct tool for the job; the only widespread criticism I've heard is that it doesn't produce documents accessible to the blind. (And I've heard that work on this is in process.) I tend to be unsympathetic to criticism that a tool is "outdated"; if a tool is right for the job, why change it? But I want to keep an open mind -- what would you like to see in LaTeX's place?
    • andi999 5y ago
      My pick with Latex is: Error messages look to me as complicated as C++ template errors, packages sometimes don't work well together, a lot of boilerplate is usually needed, and I feel somehow the Syntax needs too many keystrokes, like why not make {} for sub and superscript optional and everything until the next space character is sub or superscripted (and not only one character). Also writing {\rm text} feels wrong. Shdnd it be \rm {text} and maybe instead one shd be able to use $ in an equation block to get to a non italic font. While markdown is not advanced enough, I feel the making it easier for the user to use is the right modern approach, from which maybe a full system could be designed. Also figure placement should allow more fine-tuning (not sure how, and yes this is against the original spirit)
      • BeFlatXIII 5y ago
        Might the {\rm text} notation be LISP-inspired syntax? Replace the braces with parentheses and remove the slash and you get `(rm text)`
        • andi999 5y ago
          Somehow \mbox is the opposite though (see the examples) : https://www.tutorialspoint.com/tex_commands/mbox.htm https://www.tutorialspoint.com/tex_commands/mbox.htm Honestly I think I am missing all the points about brackets in Latex, if somebody knows the Syntax (and the 'why' pls tell me).
    • GiovanniP 5y ago
• zibzab 5y ago
  Here is an idea: Stop adding crazy marcos and customization and use it like an editor instead of an OS. I understand this is a very controversial idea, but I have learned that since I'm switching machines and using remote boxes all the time, customising everything 100% to my liking is neither possible or worth the effort. This of course requires the emacs team to make the barebone emacs a little bit more functional. Otherwise we can simply use uemacs or mg and benefit from faster startup and lower footprint.
  • slapfrog 5y ago
    I revisit my emacs config once every year or so, but otherwise I leave it along and focus on using emacs instead of tweaking emacs. From what I've heard, some emacs users seem to get addicted to tweaking emacs, so much so that it distracts them from their real work. But that's just not something I can relate to myself, nor is it something I've witnessed from my emacs-using coworkers and friends. I've also perceived an uptick in hand-wringing about such emacs-tweaking in the past few years, seeming to correlate with an uptick in handwringing against GPL licenses and GNU in general, and I wonder if agitation with RMS has something to do with it.
  • rgrmrts 5y ago
    I use emacs to interact with other machines or remote boxes. All of my customizations and preferences are magically applied to remote files. For example, I wanted to edit a file in the Hetzner rescue image and I just opened it using tramp and wrote my changes. If I were to use emacs as just an editor, I’d probably stick with sublime or vscode or something. The same UX across many common workflows is precisely why I prefer emacs.
  • dangirsh 5y ago
    What do you suspect the "macs" is short for?
    • bigbillheck 5y ago
      "Megabytes And Constantly Swapping".
  • 5y ago
• playcache 5y ago
  This is why I don't bother with emacs, I just don't have the time to sink in the first place. Now that I have a young family and hobbies outside of work, I don't have the time to spend hours fixing and tinkering a setup or learning an already opinionated set up like spacemacs etc. I just use an IDE which is already set up with good defaults and I have a well settled vim config for driving remote machines or changing something on my main PC. I also cannot get on with the shells available in emacs. They feel slow and have to many quirks and I don't get that with vscode / intellij.
  • blacktriangle 5y ago
    Emacs gives you back what you put into it. There's absolutely nothing wrong with using it at a very basic level, and getting to that point takes minimal time. There's a 15 minute interactive tutorial linked from the start screen at which point you're fully able to get work done. You can then reach for other goodies like Org, Magit, various interactive shells, tetris, whenever you want/need. I probably used Emacs for 5 years straight before installing a single package other than color themes. To me the pitch for Emacs is it's the same overall platform now as it has been for decades and will probably continue to be. While all my colleagues were jumping from BBEdit to TextMate to Sublime to Atom and now VSCode, I've just been sitting here editing text.
    • na85 5y ago
      I say this as a 10+-year emacs user: The "15 minute tutorial" is emblematic of everything wrong with emacs and its community. Just make CUA-compliant keybinds the default, and you'd draw in so many more users. The ideal tool is one that you can start using right away, and incrementally dig into as you descend into madness/poweruserdom. The idea of having to waste 15 minutes before you can even start working in emacs is awful. I used emacs for quite a few years only knowing how to save/open files and undo, because I refused to go through a tutorial that looks like it's stuck in 1970. I'm sure many others just give up and use vscode.
      • iLemming 5y ago
• danShumway 5y ago
  It does kind of bother me that Org doesn't have a particularly good formal spec. There are a ton of parsers out there, which is great, but there is no Emacs-independent set of tests you can run against a parser to figure out if it's compliant. Ultimately, the Org format is what Emacs says it is, and everyone else just tries to play catch-up. I feel like this is a little bit of a missed opportunity. I use Emacs because I think it's (for me) the best editor that exists today, and it's likely to continue to be the single best editor that exists (for my needs) in the near-to-long-term future. That doesn't mean I'm necessarily pleased about how much Emacs tends to suck features into itself and how hard it is to get them out. I don't like that the "canonical" version of Org-mode is Emacs dependent. I don't like that when I manage my life through Org-Agenda it becomes needlessly hard to work with other tools unless I sit down and find a partially functioning Org parser on Github that may or may not be abandoned. Yes, Org is plain text, but being plain text isn't good enough, it also needs to be easily parseable into a consistent AST or formal data structure on multiple platforms. I don't like that when I write a tool in Emacs Lisp that I can't run it headlessly anymore, and that it now requires a massive pile of dependencies to run. The Tern language server was a good development on this front, it's good for language formatting tools to be separate from editors. I wish more parts of Emacs would work that way. But it's not so much of a problem that I'm willing to give up Emacs to in order to cobble together a system that adheres more to the Unix philosophy of being more composable. The lock-in effect is definitely real, it's just that Emacs also happens to be good enough right now that I don't have anything else I particularly want to move to, which makes the lock-in a lot less annoying. I'd move off of Emacs if I felt like any of the other editors were better, but I don't, for me none of them come even close. Emacs has a huge community and a huge featureset that dwarfs other editors, and it also has this core of flexibility and transparency and extensibility that I feel even "configurable" editors like Visual Studio and Atom haven't really caught up with. But importantly, me saying that Emacs is the best editor around is not quite the same thing as me saying that Emacs is good. I don't have any regrets picking up Emacs, at all, it was a great choice and it's paid off tremendously, and I think it'll continue to pay off in the future. But I do wish there was a better editor out there.
  • neolog 5y ago
    What is the advantage of plain text? Other than that Emacs is bad at editing other file types.
• lgrapenthin 5y ago
  I am also a 10+ year GNU Emacs user. I haven't customized it beyond font size and a few settings. I even use the default theme. Other users seem to go crazy and try to make it into a spaceship. Then they claim that it takes a lot of time to customize it. It mainly is very different to operate from all programs and window managers that we are used to these days, and people perceive this as a wrong and try to "fix" it with confusing "starter packs". In reality, its meta features and comprehensive reference documentation make it a closed environment that is very pleasant to navigate.
  • tech_tuna 5y ago
    Same here, I'm mostly sticking with it because of muscle memory at this point, definitely not because of RMS. I may switch over to a new school UI based editor one of these days. I used VSCode for a bit but got sick of it. Like OP, I really wouldn't recommend emacs to anyone just learning.
  • cpach 5y ago
    I agree – Plain Emacs works very well. My current ~/.emacs is 27 lines (comments included).
  • timbaboon 5y ago
    Totally with you on this. I’ve added some stuff for coding in Python, but really minimal changes. 10+ years later I’m still happy and use it daily.
  • loopz 5y ago
    While making notes about config & tips for various linux software, the bar in my book is actually wether you can live with the defaults and how little tweaking something needs. It's the exact opposite of sinking costs, and rather focus on "good enough" because you often end up switching or changing stuff soon enough anyways. So more like how fast can you just go from default install and choose the sanest defaults and not spend time on tweaks / unix pr0n. Install what you need just in time etc. It makes even more sense when using defaults on several remote systems, kind of like just using vi.
  • BeetleB 5y ago
• itronitron 5y ago
  I think the lock-in effect is driven by a desire to retain (and easily access) memory of prior experiences (emails sent, bugs fixed, etc.) and not based on 'investment made' The sunk-cost fallacy doesn't really apply here because the time spent using emacs in the future would be spent on any tool that was chosen instead.
• pkulak 5y ago
  So, that's NOT the sunk cost fallacy. If you are still getting benefit from the cost, it's not sunk*. This is just not wanting to invest time into a new system while you're still productive in the current system. A sunk cost would be like, "Well, I spent $100 on this steak, so I'm going to finish it, even though the next bite may make me vomit." In that case, you paid for the steak, it cannot be returned half eaten, and eating more of it will bring you zero benefit, so the rational behavior is to not eat more of it. EDIT: It's not a "fallacy". It is still a sunk cost. My mistake.
  • Jtsummers 5y ago
    A cost is a "sunk cost" when it's already been spent and can't be recovered. The time invested into learning and configuring emacs is a sunk cost. The fallacy is in persisting with it when other tools may be better, choosing to persist because of the time invested. Continuing with emacs because of that time investment even when there are better tools (for some part of the work at least) is an example of the sunk cost fallacy. Now, that doesn't mean that the tradeoffs can't be considered where someone determines that emacs is better to continue with for them in their particular situation (regardless of the sunk cost of time spent on it).
    • pkulak 5y ago
      You defined a sunk cost properly, but that's not the same as the "sunk cost fallacy". To abuse my original example some more, when you are hungry, the steak is still a sunk cost, but it's obviously not a "fallacy" to eat it then. EDIT: Just realized what you are responding to. I'll edit my post. Thank you!
  • Barrin92 5y ago
    I think it's an overused concept because it's exemplary of a larger cultural issue. People praise 'openness' and optionality, (not just in software tools), and are skeptical about any form of commitment simply because it closes off some paths. In programming it comes up a lot with opinionated programming languages, IDEs etc. Environments like Emacs with their idiosyncrasies and age tend to be disregarded because they aren't all things to all people.
• samatman 5y ago
  I don't know whether or not it's a perfect translation, but from his description I would offer "tunnel vision" for Scheuklappen-Effekt. Emacs is a truly remarkable program, which has painted itself into a corner. There are just too many locked-in architectural decisions to make a complete list, and it's good enough at being what it is to suck up all the oxygen needed to build another text editor which could overcome the 40+ year head start it has on anything else. Org-mode is the perfect example of what's right and what's wrong with Emacs. It's great, and it's also a weird ad-hoc format, most of what it does shouldn't live in an editor, and if you want to really use it anywhere but inside emacs, good luck to you. Remarkably powerful for a TODO list which evolved sentience! I'm heavily invested in doing something about all this, but since none of that code is public yet, I should probably stop faffing about on HN and knock off another issue before the weekend arrives...
  • asciimov 5y ago
    My first thought for the Scheuklappen-Effekt was blinders. Blinders are used to prevent horses from seeing sideways. Turns out, blinders are also called blinkers.
    • CRConrad 5y ago
      > My first thought for the Scheuklappen-Effekt was blinders. Blinders are used to prevent horses from seeing sideways. Yup, that's what Scheu-klappen means. "Shy-flaps", to use the English cognates: Flaps you put before (beside) the horse's eyes, to stop it shying away whenever it gets spooked by something it sees off to the side. > Turns out, blinders are also called blinkers. Funny how the adjectival form (gerund?) is apparently only used on the latter variant: I've only ever seen "that's a blinkered view", never "blindered".
  • na85 5y ago
    >if you want to really use it [org-mode] anywhere but inside emacs, good luck to you I wonder if org could be ported to provide a language server via lsp, and in so doing become cross-platform? Org really is a superior markup format.
• AlbertCory 5y ago
  When I was at Oracle in the 90s, I was constantly having to sit down at someone else's machine (this was before covid, of course). And there were zillions of Unix versions, not just Linux. You couldn't even count on emacs being installed, but I drew the line at learning vi, other than :q! If they'd been editing, I'd ask them to save it. What that meant is, whatever customizations I had on my own machine were not available. I had to learn to work with the defaults. This is liberating. I recommend it.
  • iso1210 5y ago
    I agree, I've used vim for 20 years with very little in my home vimrc file. Indeed I didn't even have a vimrc file until Vim 8 changed a bunch of defaults to make things worse, which almost made me quit, until I realised the alternative was nano.
    • abzug 5y ago
      The alternative could be vi/nvi.
      • Koshkin 5y ago
        or elvis https://en.wikipedia.org/wiki/Elvis_(text_editor) https://en.wikipedia.org/wiki/Elvis_(text_editor)
• _huayra_ 5y ago
  I wish there was a solid competitor to Emacs, but the thing that keeps me coming back is that I have the time to tinker with it a lot and the community is great. Vim and Vscode have some valiant maintainers of projects, but from what I've seen it's nothing compared to the big Emacs projects, especially Org mode for which I haven't found a reasonable alternative in Vscode. However, I don't like fact that most of the editor is a single event loop. This is not a big deal most of the time, but if, say, you're using magit on a large repo and a command finishes and the buffer must refresh, you're gonna wait there for several seconds being unable to do anything else (no switching to other buffers, much less continuing to use Magit while it is updated asynchronously). (btw if I'm wrong about this, for the long of god enlighten me!) elisp is a bit quirky and dated, and very hard to figure out incrementally. I am still at the place of "copy-paste from other smart people's configs" because I have not really sunk the time to gain a deep understanding of the language; the lack of types and a somewhat tricky (although functional) debugger prevents many of the things about the language from being elucidated, especially because the powerful macros. However, I don't really know what an effective alternative would be besides perhaps Javascript (which I'm also not a fan of) or Python.
  • rich_sasha 5y ago
    I have found it very difficult to pickup elisp, but the latest concerted effort worked. I found learning it to be a very fulfilling experience.
    • _huayra_ 5y ago
      Was there any resource that help you get over the understanding hurdle?
      • alex_smart 5y ago
        Emacs comes with everything you need to learn emacs-lisp. Take some time to familiarize yourself with the help facilities* and then jump over to info, start with "Emacs Lisp Intro" and eventually continue with "Emacs" and "Emacs Lisp". * At the very least, familiarize yourself with "C-h f (describe-function)", "C-h v (describe-variable)" and how to read info pages. To view what other help facilities emacs provides glance over "C-h ? (help-for-help)".
• clipradiowallet 5y ago
  I admire emacs folks, for the same reason I'm a 15-20 year vim person. If someone uses emacs regularly - they most likely know what they are doing, and we can get along on that basis. I appreciate the authors introspection and honesty about using it though, was a good read.
• ta_emacss 5y ago
  when you are looking for a tool as a programmer, the question you should be asking is not 'is it complex?', the question always is 'is it worth it?'. emacs is the only tool in existence i can confidently say yes, every bit. as a programmer you should be using emacs. i have used visual-studio for 8 years then vim for at least 5, emacs was always there taunting me. after 'evil' i had no reason to avoid it and i wish someone told me to use it the day when i started coding. this is not vim-vs-emacs, this is not ide-wars, they are for language-lawyers and influencers spewing bullshit for internet points. magit, tramp, org-mode, evil... every one of them are free, orthogonal to rest of the emacs-system, supported on every os. but emacs too comes with a curse, just like lisp. after you get used to it, there is no going back. everything is going to feel inferior.
• dleslie 5y ago
  Every so often I would start my Emacs config over from scratch. I might port over some old defuns from the previous, eventually, but I would always endeavour to try the latest tools and best language configurations. Consistently I found myself using Emacs and sticking to it because it offered the best developer experience. And then came Microsoft's Language Server Protocol. Emacs was late to adopt it, and still has generally spotty support for it. This has caused me to stop using it, almost altogether, as Emacs is objectively inferior because of its poor support for LSP. Its largest competitor, VSCode, Just Works most of the time! You load a file, it detects your intent, and it will install the necessary extensions _along with any additional system packages necessary_. Compare this to Emacs, where it's usually quite unclear what packages to use and what tools they need to operate. Eglot? lsp-mode? Which language major mode, and which language server? How do I get them to work with company mode and so forth? And then when they do work, the packages often drift and break. I had C# working quite well with lsp-mode and OmniSharp, and then I updated Emacs. Without any changes to my configuration the experience has become atrociously slow, and apparently this is due to a known and recently introduced bug in Emacs support for C-style modes. I strongly recommend other Emacs users shake the sunk cost fallacy and just try the competitors.
  • BeetleB 5y ago
    This makes sense primarily if you assume people who stick to Emacs do so because of its SW development capabilities. As a person who hangs out amongst Emacs communities, this profile is not the norm.
    • dleslie 5y ago
      I used Emacs for software development and git interfacing. I tried organizing my knowledge with org-roam. I tried maintaining org todo lists. I tried having an active org-agenda. I tried... But what I do more than eight hours a day, every week day, is read, write and debug code. Emacs was once the best, it is now not so great. I've been using Emacs for over two decades, now. It's painful that it fell behind so quickly.
      • 5y ago
• gumby 5y ago
  The flexibility is a distraction. I've been using Emacs for over 40 years and have a very small init file which is gets modified once or twice a year at most -- most of the time not at all. It's simply a powerful tool. Not the only one I use, but certainly it's easier to type to it than it is to type, say, to the input box here in my browser (even though it has at least some emacs commands built in).
• submeta 5y ago
  I loved tinkering with Emacs, reading through code of packages like org-ql, writing my own helper functions in Elisp, migrating every tool I use to Emacs (Editors, IDEs, file explorers, diff tools, dedicated markdown editors, and many more). At some point I realized I was spending more time configuring Emacs instead of doing work. I have a tinkering-vs-doing chart in my mind where both activities are on opposite sides. With a limited amount of time per day, I was on one extreme side of this diagram (tinkering a lot, getting not much done). When I took over new responsibilities, I could not justiy this time anymore. I had to move quickly and deliver results. That‘s when I went back to dedicated tools (Ulysses app for writing markdown, Notion.so as a personal wiki (previously org mode), Logseq for personal notes, VSCode and PyCharm as an excellent Python IDE, etc. Now other people work intensely to perfect those dedicated tools. And I can solely focus at the task in front of me. With this shift in focus my productivity increased immensely. Now I still use Emacs. For text editing purposes. And I use macros a lot to transform text. But that‘s about it.
• ashton314 5y ago
  Perhaps an overlooked aspect of Emacs that makes it so attractive is for those of us with some kind of RSI or other accessibility issue that makes customizability a must. I'll admit, I haven't used other editors all that much, but Emacs' keyboard-first approach makes it a much easier tool for me to use than other editors that require some kind of mouse interaction for certain aspects. I've been able to customize Emacs to have more ergonomic keybindings (e.g. I use evil-mode and evil-leader for a lot of common-use functions) and my RSI has never been better! Granted, some of that RSI was due to how I had Emacs set up before. Not all of it, mind you, just some. I have repented of my non-ergonomic ways.
• iLemming 5y ago
  I said this before in regards to choosing Emacs or something else. I'll repeat it here again. There are always multiple paths to get something done. Some people prefer automation. Having "a bucket of bolts and nuts" makes it possible to hack your way around things. Some people like Ferrari. But for many - the utilitarian value of that car is infinitesimal. Instead, they'd rather have exactly what can be described as "a bucket of bolts and nuts". They cannot go camping in a Ferrari; or take their beloved bullmastiff to a vet in it; nobody drives a Ferrari to help their friends to move furniture. Emacs is "a bucket of bolts and nuts" and not something akin to a shiny, expensive but not very useful car. It's more like a transformer - you can build a pickup truck, a camper, an ambulance, or a race car. And that's what makes it a fantastic tool for some people and an immense pain for many others. Some people like Ferrari. And there is nothing wrong with that.
• anothernewdude 5y ago
  I have been keen to find an alternative editor. But it needs to be as customisable and scriptable as Emacs is. And nothing has come close so far. (Having an editor use electron is a non-starter)
• SirensOfTitan 5y ago
  I maintained my own emacs config for a while and ended up moving to Doom mainly for a more thoughtful shortcut config. I spend a couple hours every once in a while tinkering for fun (and to fix issues with my workflow). Sure, you may be tinkering more in emacs and working less, but free play is an integral part of growing skills, as is feeling a sense of joy when using your tools. It’s okay to do things without a goal in mind.
• anyonecancode 5y ago
  Interesting post. I'm ~6 mo into using emacs, but I'm a long time vim user. I use emacs for org mode and org-roam, and for personal finance[0]. And sometimes, magit for git. And honestly... I may never use it for much more beyond this, and that's totally fine with me. Which I suppose is the point of flexibility -- people can use a flexible tool in the way that works best for them. My contribution here is to note that its _also_ ok to decide a tool, even an impressive tool, is something you only want in a few specific contexts without feeling bad about not adopting it everywhere. I think its working out that way for me because I'm not actually much of a tinkerer. I very much like the straightforwardness of plain text, and I like all tools that empower me to put that in the center of my workflows. I can take or leave emacs, but I love org-*. Actually not too different from how I got into programming in the first place -- being able to write a plain text file in a certain format, point my browser to it, and boom it's a web page, was magic. And from there into actual programs -- use a certain format and boom it does stuff... The tools themselves - eh. Keep it simpler and I'm happier, but I'm not much for customizing them. I can see how for the tinkering personality one can really get into emacs. That's not me, but emacs works for me for some things, and I've been happy to learn it for those. [0]https://github.com/beancount/beancount-mode https://github.com/beancount/beancount-mode
• jonnycomputer 5y ago
  I use a variety of editors is a ad-hoc way, mostly because for any specific ad-hoc task, one or the other makes it easier to do. For example, creating a scratch buffer (note, not *scratch*) is just easier in BBEdit than Emacs, because all I do is open it and there it is. That said, I do most of my programming in Pycharm these days, and I don't regret it. As for emacs, I use it just about every day, and I think one of the best things about it is that Emacs will be Emacs whether its 2021, or 2031. Its a lifelong tool for a hopefully long life.
• bborud 5y ago
  I've used Emacs for 32-33 years and I can't even imagine how many lines of code I've written in it. Every 2-3 years since the early 2000s I would try an IDE for 1-2 months, but then go back to Emacs again because I was simply faster in Emacs and because the IDEs were supremely ugly, resource intensive and slow. A few years ago things started to change. IDEs started to become less clumsy. Less horrible to de-fang to the point where they became tolerable. They might have gotten a bit faster too. Then some time around february this year I felt it was time to give IDEs a try again so I spent about a week configuring VS Code to where it was tolerable. Mostly by removing visual noise. All keyboard bindings etc are standard because I think you ought to learn how to use a tool as close to its default configuration as possible because that means you can make use of the knowledge of other people. Now, about 6 months later I think I might stick to VS Code for programming in the foreseeable future. Here are some reasons why: - The support for various languages in Emacs just isn't being maintained. Every so many months my setup for Go would break hard, and along the way small things would constantly stop working and I would have to figure out "what the heck happened now" and hack my way around it. Or shrug and say "okay, so that's gone". This was no different in C/C++, Java and other languages in the past. - Emacs doesn't have a sufficiently large active developer base. Not only does this lead to poorly maintained language support, but it kind of goes against one of my basic rules for choosing tools: no marginal stuff(1). And Emacs has become marginal. So while I love Emacs, it no longer qualifies as a viable tool in my eyes. - Emacs isn't going to catch up with VS Code. And I don't think many long time Emacs users want to. They just want to be left alone. Emacs has too many failed attempts at making configuration and adding third party code work well (it really doesn't) and even work with the reams of elisp code each of us tend to end up with after years of trying to get broken stuff to work. Enough for us to develop Stockholm syndrome and thing we want all this chewing gum and duct tape holding things together. - I don't like JS and its derivatives (like TS) and my dislike is almost militant -- but it beats elisp hands down on every metric that actually matters in the real world: chief among them the number of decent developers who will write and maintain extensions. As I said, I still love Emacs and I've written close to 100% of my code in it for 30+ years. But I've kind of arrived at the conclusion that it isn't going to evolve fast enough for it to be an attractive option. VS Code is far from ideal. For one it is written in a language I detest. But it is better for programming Go, and C++, and C and probably java (I haven't written a line of Java for 4 years so I don't know). Yes, it has shortcomings, but fewer than Emacs if your focus is to be a productive programmer and not muck about fixing poorly maintained bits that suddenly stop working. If people think 30+ years of using Emacs represents an investment they can't afford to throw out I seriously doubt they have really tried. I also think people underestimate their own ability to rewire their brains. I turned 50 this year. I'm extremely conservative when it comes to tools, languages, operating systems because I'm just not that interested in wasting time tinkering with my environment: if it works it doesn't need messing with. If I can get comfortable with a different environment for programming in a matter of weeks, so can anyone else. (1) I try to avoid using tools and software that has too few users. Sure, there may be better tools, but tools with small audiences tend to not be well maintained over time. Few users also means fewer solutions you can find online to problems you might have. Pick tools that have large audiences and you will find people that have had the exact problem you are trying to solve. I apply this when choosing OS, language, hardware, tooling etc.
• ThinkBeat 5y ago
  The wonderful thing about Emacs is if you learn it well it is a tool that can stay with you and has stayed with you for decades. I only have a couple of years invested and that was years ago. Since then, I have had to use a lot of different editors and IDEs. Due to job changes, different programming languages, platforms, and market forces. Each one has cost me some time, sometimes considerable time to learn well enough to be productive in it. But they are all ephemeral. X number of years down the line it disappears for one reason or another and the entire investment is lost. Had I stuck to Emacs (which would be impossible for some of my jobs) I could have gotten much better at using it and that investment would still be worth something today.
• rrock 5y ago
  One of the major things that keeps me in Emacs is the keyboard macros. Being able to record a key sequence is something that I use regularly, and I don’t think the major competitors have it yet.
  • AtticHacker 5y ago
    Keyboard macros are great! Although after discovering multiple cursors I found less use for them. 90% of (my) use cases were easier to solve using MC rather than keyboard macros.
• teunispeters 5y ago
  I haven't sunk much "effort" in it. I use it as a syntax highlighted code editor that can load multiple effectively unlimited size files without usually too much issue, recover cursor positions on restart and doesn't suddenly pause and lock up when scrolling. Oh and I need page up/down, home and end of a line as well as doc, and reasonably good cut and paste. Note : to date, this means it has no competition, except in much more limited editors, like vi and jed. None at all. So far every other package has lost out. And when it's gotten close in capability, it's required it's own walled gardens and can't handle project structures outside of its own. So yeah, as yet there is no competition to emacs. Maybe someday there will be. Some givens: - it cannot be nodejs based. Has halting randomly, random crash, inability to save and recover and excessive CPU and memory consumption, even with other features covered. - it cannot be one of the many code suites. They all (so far) require projects to be in their Pet Project Format. Useless if one's working on corporate git trees (or other repos), or for that matter linux kernel. - it needs to support many code languages. I do work with lisp, python, bash, C, C++, C#, Java and who knows what else. Just not elisp, not if I can help it ;) - it needs to coexist with the rest of the environment. Cut and paste has to go between apps, not just itself. (you'd think this was common, but eclipse showed me otherwise) - It has to be either UTF8 capable, or binary. Or both. I mean I've locked emacs up a few times - always with particularly large files ... but this is very rare. oh yeah, emacs user since 1991. I've tried Visual Studio (still have hope on that one, should their linux support finally be good), Eclipse and family, Atom, Code (see Visual Studio), vi, jed, edlin, wordpad, borland C++, turbo pascal and too many other better forgotten systems.
• lkrubner 5y ago
  I'm currently hiring 5 software developers for a startup that I'm consulting with. On some level, I'm aware that it would help team cohesion if we could all use one text editor. But for the most part, it's a decision that I leave to each developer, as it is a decision that can be left to individuals. If we were going to use a language such as Clojure, where the whole eco-system tends to use emacs and offers examples in emacs, then I might try to introduce emacs, but the opposite is also true: the feeling that developers should learn emacs is one of the things that makes me wary about recommending Clojure to clients, even though Clojure is the only language I use in my personal projects. But for this current client I think we will mostly be working with Javascript, so I think most of the people we hire will be happier with their IDE of choice, or with Sublime. I do wish something like emacs existed in slightly more modern form. I'd be thrilled if there was a modern text editor that allowed me to customize the app however I wanted by writing additional code in the language that the text editor is also written in (that is, repeating the relationship that emacs has with elisp). But it seems unlikely that anything like that will ever exist, so I go on using emacs, but I don't recommend for any clients.
  • resoluteteeth 5y ago
    > I do wish something like emacs existed in slightly more modern form. I'd be thrilled if there was a modern text editor that allowed me to customize the app however I wanted by writing additional code in the language that the text editor is also written in (that is, repeating the relationship that emacs has with elisp). Is there some reason you don't consider this to apply to vs code?
    • lkrubner 5y ago
      VSCode is very good. I could write something about Lisp being homoiconic, also I don't know the VSCode equivalent of "advise", macros rewriting core functions of the editor, but I'll let someone else make that case, if they feel like it.
    • alex_smart 5y ago
      The process of writing Emacs-Lisp: open the scratch buffer, write a function and eval. The process of understanding what any part of the editor is doing: C-h f <function name>, read the documentation and link to the source is again right there. You can go to the source, set up a breakpoint, step through the code, understand it and even modify in place if you feel like it. There is no other environment I know of, apart from smalltalk, that makes the process of extending and customizing the environment that frictional-less. I have tried to understand the process of extending vs code, but it seems to require a lot of ceremony. https://code.visualstudio.com/api/get-started/your-first-extension https://code.visualstudio.com/api/get-started/your-first-ext... For instance, everything needs to belong in an extension, and you run the extension in different instance of vscode rather than the one in which you are editing the extension, which you have to reload/restart everytime you change the extension's definition. The difference in experience is similar to the difference in experience in REPL-driven development in an interpreted language v/s developing in a compiled language with the whole edit/compile/run cycle.
• ilovecaching 5y ago
  People are treating Emacs as though it's an editor competing with other editors. It isn't. Emacs is a lisp environment. The editor built on top of that is at the same level as the IRC modes, mails modes, org mode, etc, etc, etc. Emacs is an entire programming operating system you never have to leave. It's not even close to the same as VS Code.
• singingfish 5y ago
  I've been using emacs since 1993 (with a long gap between 94 and 99 where I barely used computers at all). I like to say that it was the only thing that remotely made any sense on the X-windows machines I had access to. I like to say I learned it then, and I haven't had to learn anything new since. I tend to declare emacs config bankruptcy every few years, so I work fairly close to uncustomised emacs.
• komali2 5y ago
  I only recently feel like I've "gotten" Emacs, to the point where I'm confident enough to tell others about my setup [1], but in the process of doing so I've realized I have so much more built-ins that I've barely touched. Like, dired. Magit, I've only skimmed the surface of. Hilariously, I only learned about apropos last week! For some reason though I gain great enjoyment from tweaking my Emacs environment (I even made my own theme [2]), and I'm productive at work, so I really can't complain :) I'm with the author though... would I recommend it? Yeeeeah maybe not, in the long run it's worth it but for new programmers no way, just use vscode like everyone else. [1] https://blog.calebjay.com/posts/my-emacs-environment/ https://blog.calebjay.com/posts/my-emacs-environment/ [2] https://github.com/komali2/Emacs-VSCode-Default-High-Contrast https://github.com/komali2/Emacs-VSCode-Default-High-Contras...
• RHSeeger 5y ago
  I use IntelliJ every day, to program Java (and some other things) for work. I use Emacs every day, to do other things for work. For quick, powerful text editing, there's just nothing that compares. For many things, it's faster to start up Emacs, do it, and close it... than it is to just do it in IntelliJ, which I already have open. Different tools for different things.
• SquibblesRedux 5y ago
  I used to use Emacs for large files and vi for small, quick edits. I am now using VS Code for large files and still vi for quick edits. The single feature that got me to switch from Emacs to VS Code was the ability to use a mouse for navigation and selection. (My Emacs and vi usage was always in a terminal.) I had tried XEmacs for a while, but found it too aesthetically displeasing. I would be happy to return to Emacs if there was a front end that worked well and was standardized across all windowing systems (Linux/Mac/Windows).
  • alex_smart 5y ago
    > I had tried XEmacs for a while, but found it too aesthetically displeasing. Why would you even bother with a fork whose last release was 12 years ago? :\
    • frosted-flakes 5y ago
      Maybe that's when they tried it. Does it matter?
      • alex_smart 5y ago
        Erm, yes. Their complain was about aesthetics, and GNU Emacs has been much more aesthetic than XEmacs since forever.
        • frosted-flakes 5y ago
          True enough. Do you mean it had much better aesthetics? Something can't be more aesthetic, that's like saying it's more temperature outside when you mean it's hotter.
          • alex_smart 5y ago
            Yes, considering what XEmacs looked like, I would say that newer Emacs look considerably more aesthetically pleasing. And with certain themes, Emacs can look outright gorgeous.
• aaronchall 5y ago
  If I want to take notes on code in various arbitrary languages I would use emacs because I can evaluate them all in the same note file. I think there are other editors or systems that give one a multi-language notebook. But having already learned emacs, org, and org's code blocks, the marginal cost of using something else is much higher. For me, sunk cost isn't the issue. It's the marginal cost of doing the next thing. And that's why I chose to sink so much effort (cost) into learning emacs - I knew it would pay off for the rest of my life.
• p4bl0 5y ago
  I've been using Emacs for almost 15 years now. At some point I even did my emails (using mu4e) and social medias (twitter and identica at the time) with it, in addition to all my work. My Emacs was heavily customized and I spent a lot of time fine tuning it to my likes and needs. About two years ago, I switched to KDE (from nothing except the Openbox window manager). I wanted to give Kate a try. It's a very decent editor but it was really hard for me coming from my all powerful Emacs setup. It did not really last, but it made me realize that I was originally using Emacs because it is free software from the GNU project, but it was still a jail to me as I was at a point where I had a hard time being efficient anywhere else, even in a vanilla Emacs without all my setup. Since then I'm still using Emacs but almost vanilla (only minor adjustments — my .emacs.d/init.el dropped from several hundreds of lines to a couple dozens) and not exclusively Emacs. Even for text editing I sometimes use Kwrite or Kate.
  • maydup-nem 5y ago
    > My Emacs was heavily customized > several hundreds of lines amateur
    • p4bl0 5y ago
      That's just the init.el file. I had several custom Emacs packages loaded from it ;).
  • dotancohen 5y ago
    That experience is not exclusive to Emacs. I'm a VIM brat and simply cannot use any text editor that does not speak at least a basic VIM dialect. Thankfully Jetbrains' IDEs have IdeaVIM. I firmly believe that text editor proficiency is handled in the same part of the brain that handles language. I notice very similar obstacles when switching or learning or trying a new text editor as I do when switching or learning or trying a new language. And those are both something that I do every few years.
• dgan 5y ago
  Every time i tried Emacs, i found that I would be more productive using something else. Still can't find a use for it.. I do use vim tho, as it comes with default installation and has useful regex search, nice to quick edit files
• richardjdare 5y ago
  I like Emacs because it's a live programming environment focused on the editing of text. As far as I know, there is no other editor with this capability. Sure, they all let you write "plug-ins" but none of them let you do your work by writing code interactively, alongside normal editing commands and GUI operations. As a programmer, this is how I want to do everything with my computer. I don't have many customizations (I have something to move lines with the alt-key like Eclipse, and I swap parens and square bracket keys so it's faster to write Lisp) and I don't even know many keyboard shortcuts, but I write bits of Elisp all the time to perform large scale text manipulations, generate Java and html boilerplate at work etc. Having everything happen inside my editor, being able to use an editable buffer as an ad-hoc input source to a program just makes everything more fluid and interactive than doing the same thing with scripting languages on the command line. It kind of baffles me that the Emacs people don't push this angle very much. There's hardly anything about it on the website. You'd think Emacs was just another editor with hundreds of keyboard shortcuts and a strange gui.
  • kqr 5y ago
    I'm not that surprised. It's the sort of thing you won't appreciate until you've tried it. Ask people what they want, and they'll tell you "a faster horse". Ask people what they want, and they'll tell you "a better editor" so that's how Emacs markets itself. Unless you've tried one, "a car" or "a fully dynamic, programmable editing environment" is just not on people's minds.
    • andi999 5y ago
      I don't understand it. Any examples how to do that in practice? (used emacs for a couple of years, but just as a editor)
      • githubalphapapa 5y ago
        The question is almost like asking a fish to describe water. It's the sudden lack of it that produces a really clear example. :) Anyway, here's a random example that comes to mind: I have some sexps in a Lisp file and I want to sort them alphabetically. Each sexp (usually a top-level form, but not necessarily) usually spans multiple lines, so line-sorting won't do it. Since they may be top-level forms, there may be comments between them that would lose their context if their position relative to sexps were lost, so comments need to "stick to" sexps they're above. How would you solve this in a random text editor? In Emacs, I would develop a command that does what I need. At each stage of the development process, I evaluate the command's definition, and it's instantly available to be used and tested. I could even test the function on its own definition, if I wanted to be silly (undoing the sorting after testing, of course). When I'm done, I save the command definition to my configuration, and it's now a permanent tool in my toolbox. I didn't have to recompile the editor and start a new process, nor did I have to submit a patch to an upstream and ask for it to be merged. Similarly to a carpenter (forgive me if it sounds silly), my editor is my workbench, and as wood is malleable, so is my editor. So, here's the command I came up with (maybe not the prettiest implementation, but maybe not the worst): https://github.com/alphapapa/unpackaged.el#sort-sexps https://github.com/alphapapa/unpackaged.el#sort-sexps And using Emacs and Org mode, I publish it into this "unpackaged" package, which I then install into my configuration as a package, and other users can then easily install it into theirs, too. I don't know of any other editor that can do all of this, certainly not so easily.
• dredmorbius 5y ago
  The passage that stands out most to me is this: [W]hatever I've learned for technologies like Emacs, LaTeX, GNU/Linux, and so forth in the nineties, is still valid and useful to me nowadays. This can not be stressed enough: instead of un-learning and re-learning, I was able to improve and learn new things. This scales much better than any proprietary or temporary knowledge. Even though I don't use emacs,[1] the point here is one that I've long realised and was instrumental when I was looking at potential directions to go with technology in the early 1990s. I'd had experience across a number of computer systems, small and large, and all but Unix were proprietary. I'd already seen hard-won knowledge expired, often in a few years, as platforms or tools were eclipsed. And Unix was more fun... Learning vi on the uni shared-access Unix server in the 1980s was a few weeks of pain and confusion. It's paid off handsomly over the subsequent 35+ years, as did basic fluency in the shell and its tools. Over time I've added to my toolset. Very occasionally old tools are replaced entirely, though quite often replacements themselves seek to retain interface (commands, keystrokes) compatibility. I've also spent time (and occasionally money) learning proprietary systems ... virtually all of which are not entirely dead to me. Some still exist in small niches, others have all but disappeared. In Future Shock, Alvin Toffler argues that in the future (that is, now), success will be determined not by those who can learn, but by those who can successfully unlearn old patterns. The older I get, the less likely this seems to be true. Unlearning is vastly more difficult than learning. Far better to get on a technological track in which basic principles, tools, and interfaces are adopted and retained as long as practicably possible, in a modular fashion. This avoids requiring wholesale skills obsolescence, provides for maximal skills retention and accretion, and where unlearning is absolutely required, tends to localise it to specific areas. Voit's essay touches on several useful concepts directly or by reference (learning, unlearning, knowledge capital). I'd like to add another: the Lindy Effect. That's the tendency of things which have existed for a long time to continue existing. In technology it seems to be largely true. In particular, long-lived free and open tools seem to be good bets for continued relevance. ________________________________ Notes: 1. I did pick it up at one point and used it with some facility for a number of months. This was at a time that having ones own Unix or Linux server was still quite a novelty, and my manager at the next gig was an idiot who didn't believe in installing any software which wasn't shipped by the vendor. Life lesson: don't work for idiots, or let them dictate your opportunities.
• hnarn 5y ago
  This is of course anecdotal but one of the reasons I never got into emacs is because every person I’ve met who was really into it was a pathological tinkerer. I’ve worked with people who got no work done in half a day because they were remaking their config for the third time, or reinstalling their Linux distribution. I’m not trying to insinuate that all emacs users are like this but it brings me to the point of why I don’t want to learn it: sometimes the ugly way is still the fastest way, and if it works it ain’t stupid. For me, the more time something takes to get into, the higher the payoff has to be to make it worth it. For this reason, emacs has never seemed interesting to me, because it seems like the only people “saving time” in it are those that spent a decade learning it first.
• yung_steezy 5y ago
  I only started using emacs relatively recently, maybe since 2016 or so, but I use it every day. I've worked in a couple of different places in that time, first using Debian and now I've got a company macbook. By using emacs I didn't need to change my workflow at all between the two operating systems. What's more, even though I dislike macOS, I am able to enjoy using my work PC without grumbling about the OS like some of my colleagues do. As other comments have pointed out, there are some limitations to the amount of productivity that you can squeeze out of emacs vs. modern dedicated software. I can appreciate this point as a senior developer often scrambling to work to deadlines. That said, those potential gains in productivity need to be weighed against the potential loss in passion for my job that might occur if I dropped emacs.
• BeFlatXIII 5y ago
  As someone who is a basic vim editor and uses the occasional Idea IDE, would it be worthwhile to invest myself in an emacs environment?
  • johannboehme 5y ago
    Not an answer but an anecdote: I am a long time vim user and wanted to learn clojure. Everyone recommended emacs, because of it's lisp and repl abilities and ease of use. I spent two weeks learning emacs, elisp and the ecosystem. I was not able to get it to run via WSL with Frontend integration (shadow-cljs). Several help channels where unable to assist, since they all just blamed other parts of the environment (WSL, the LSP, DoomEmacs or the clojure plugin..) I eventually got it to work, just to find out, that vims minimal plugins that i used (vim-iced, sexp, and a Coc plugin) where faster, more reliable and better to use than the emacs counterparts.. and they just worked, without any troubleshooting.
  • lytefm 5y ago
    I'd say that learning vanilla Emacs and all the internals is probably not worth it. But if you'd like to try out Emacs, have a look at Doom Emacs or Spacemacs - then you can still use vim keybindings for most stuff. And just activating some of the included modules will give you enough to easily try out some of the best emacs packages out there. I wouldn't bother setting up emacs for programming, but org-mode is amazing.
• jeffyang 5y ago
  I use both Visual Studio and Emacs. In general Visual Studio does a pretty good job and it is my day to day editor. But there are some things that it's simply not worth bothering with in Visual Studio. The problem with most editors is that every buffer and every command is different. Code is different than the terminal which is different than your source control. Sorting text is different than copying text is different than formatting text. That means every new thing you want to do, even if it's small, requires you to learn how to do it the way that tool wants you to do it. In Emacs, every buffer is the same. Which means I can do all sorts of mini workflows without learning anything new. I can navigate the buffer the same way and I can copy text the same way. I can run arbitrary linux commands from my scratch buffer on buffers on multiple machines and massage the output and put it in my code buffers. I can run a macro to repeat that 1000x. Then I can tweak it slightly and run it another 1000x. I don't need to learn anything specific to my editor. I can whip this up in a minute then move on with my day because it's a one off. Yes, sort lines is available in all editors. What if you wanted to sort all the import statements in every file? In Emacs you can do a quick macro to do that. It would take you a couple of minutes MAX. You wouldn't have to even think. All because sort-lines is text that you can copy and paste. In Visual Studio... I don't even know what I would do... probably find a plugin or write a program. Imagine you found a plugin. Then imagine you didn't want to sort ALL imports, there's one import you always want at the top. Trivial to change in Emacs, not so trivial for a plugin.
• stakkur 5y ago
  I’ve used Emacs for several years now, primarily on Linux but also MacOS. I never recommend it to new users without the caveat of time investment; it’s a disservice to just say ‘Emacs is great’. It’s great in the same sense as a large box of Legos is great—for potential, not OOBE, which is (in my opinion) fairly mediocre. My second unpopular opinion: Elisp is a significant barrier to entry for users. Changing this would blow open the doors to adoption and evolving the tool, I think. But it will never happen.