9 ms·

This view is obviously biased against Emacs, but I don't disagree completely with the premise. As an Emacs user, being "immediately productive" (whatever that

This view is obviously biased against Emacs, but I don't disagree completely with the premise. As an Emacs user, being "immediately productive" (whatever that means) is not your topmost priority. You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. In a a much better way than I can put it, Emacs users are like Igors [1]. You can be a productive individual contributor writing Clojure inside Emacs, or a productive CEO managing todos in org-mode [2] – it works equally well once you figure out how you mold your editor. VSCode "plugins" and Emacs packages are just not the same, with Emacs you can be far more flexible about changing the behavior of the plugin in specific modes or activating things given specific conditions. You revel in the effectiveness of using one of the last remaining vestiges of the Lisp Machines of Old Valyria. Meanwhile company X will just slot in cookie cutter developer 1 and ask them to use VSCode because they are eager to get the developer to be "productive" on Day 1 for some reason. You would think that giving an employee a week for setting up and tuning their workflow should be totally normal if you want them be there for several years and be maximally productive over time. More power to them I guess. [1] https://chrisdone.com/posts/emacs-users-are-like-igor/ https://chrisdone.com/posts/emacs-users-are-like-igor/ [2] https://www.fugue.co/blog/2015-11-11-guide-to-emacs.html https://www.fugue.co/blog/2015-11-11-guide-to-emacs.html

TheSpiceIsLife 6y ago
I’m not a programmer, just a tradesman who’s worn a few different hats over the eons, but I’ve noticed something as I’ve gotten older and lazier: I am equally as unproductive regardless of my setup. My productivity has way more to do with all the other factors at play than it does the fine-tuning of my setup.
- michaelmrose 6y ago
  In order to be more productive of 10s of thousands of hours one only needs to be slightly more productive to justify spending a handful of hours. 1% per 10k hours is worth 100 hours.
  - TheSpiceIsLife 6y ago
    Yeah, to some extent, maybe. I appreciate what you’re saying, and I do hate being slowed down in the moment. I’ve got a handcrafted AutoHotKey script and a 22 button gaming mouse fine tuned for 2D CAD / CAM software at work, so while I am definitely in to this sort of customisation... If I’m honest with myself I don’t really get more work done because I end up using the time being unproductive elsewhere. There’s definitely a certain intellectual curiosity-satisfaction to be had from customisation. I’m just not convinced it’s a net time saver in the long run?
    - Torwald 6y ago
      > a certain intellectual curiosity-satisfaction User interface design (UID) and user experience (UX) are interesting topics. Have you ever conducted an oil change at your car or some other minor mechanical task? Wasn't it fun for a moment (at least that one time)? Machines are interesting.
    - TeMPOraL 6y ago
      > because I end up using the time being unproductive elsewhere. Isn't that literally the point? If you can do your task in 10% less time, and then end up spending that 10% procrastinating on HN, then you still win - the task gets done, and you also get to sneak in something nice. And if you find you'd rather spend that time on something else, or doing more work to finish everything faster, you can choose to do so. Optimizing work gives you choice what to do with the time saved; the default may be that you waste it, but now you have options.
      - TheSpiceIsLife 6y ago
        > Isn't that literally the point? Ah, yep, you might have a point there! Dunno how I missed that. Seems obvious now.
- deleted 6y ago
  [deleted]
smt88 6y ago
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. I've been writing software for ~24 years, and I can understand the need for this in the past. Now, I just don't get it. What are emacs users customizing so intensely that no other environment can match it? I've found that JetBrains IDEs with a few plugins do 100% of what I want, including some really advanced refactoring and useful GUI integration with CLI hinters/linters. VS Code takes more setup, but it's similar. The level of customization that emacs supports seems unnecessary to me. Can you talk about a few use cases where emacs is just better than an IDE could be?
- Reelin 6y ago
  > Can you talk about a few use cases where emacs is just better than an IDE could be? I don't use Emacs at present (Neovim instead), but I find TTY based programs to be genuinely more productive and flexible once you make it past the initial learning curve. Using tmux and ssh to seamlessly float between devices with an ongoing complex editing session immediately comes to mind. I've also used both Eclipse and Visual Studio at different times and distinctly recall what I can only describe as lumbering startup times. Ranger via ssh is often much more straightforward to use (for basic operations and browsing) than trying to click through a bunch of menus and sort out network mounting issues. Neovim does lack advanced refactoring tools out of the box, and I've never gone looking so I can't comment. I suspect Language Server Protocol may change that in the near future though. Regarding the possibilities afforded by the sheer level of customization, vim-fugitive comes to mind though I'm sure there are better examples. (https://github.com/tpope/vim-fugitive https://github.com/tpope/vim-fugitive)
  - alfiedotwtf 6y ago
    A +1 here for your comment... I have multiple machines, running Docker, running multiple tux sessions, for different projects. I can’t even begin to think how I’d pick up where I left off when switching between projects if I wasn’t using Vim
pjmlp 6y ago
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. In most jobs I worked for, taking files home from employer computers would be stealing from security point of view no matter what their contents are. So it means that one has to create those configurations from scratch every single time in each new job.
- disgruntledphd2 6y ago
  It depends on the job. Certainly you can't add any company-specific tools to your overall init file. However, most of the stuff I do isn't that specific so I have all my customisations in a git repo that I pull from github to whatever machine I'm working on.
shultays 6y ago
I think most emacs user are overestimating the gain they are having by mastering art of emacs. Sure, it sounds useful to copy every 5th character in all lines that fits a certain regular expression but how many times you actually need it on your active development time and how much time you lose by doing that manually or using more traditional tools? The coding is mostly typing and debugging. Visual studio (most ides really) is good enough at that. And to be honest emacs/vim complicates the typing part.
- bitwize 6y ago
  > Visual studio (most ides really) is good enough at that. No. It's not. Emacs's electric-indent is so close to the Right Thing when you're coding it's incredible -- getting almost perfectly formatted code as you type. Other editors have autoindent, but it never seems to do the right thing. Other editors also see fit to insert closing brackets/parens/quotes, and then miss detecting when I typed the closing punctuation so now I have three brackets/parens/quotes. It throws me off. Just highlight the opening punctuation mark when I close it, the way Emacs (and vim) does. I've given Visual Studio Code a chance. Lots of chances really. Each time I find myself struggling with it more than I should, and needing that Emacs flexibility much more than I anticipated going in. Initially I feel more productive, but the more I worked with it the more it gets in the way, inducing friction and slowing me down. And then I want Emacs back.
ordu 6y ago
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. I'm using emacs for 15 years, and it doesn't work for me. When I noticed things I'm doing often, I already have a habit of doing these things by this way. So if I wrote an elisp-function to automate things, I wouldn't use it, because my unique way doesn't include this function. I'm trying to find a courage to migrate from emacs to some other IDE, where everything already configured, where I could create new habits relying on automation. You know, like use syntax-aware indexing software instead of "<f9> find . -name *.[ch] -exec grep -Hn something {} \; <enter>". I tried etags, but it doesn't work often enough. So my unique way is to simplify workflow and start with find/grep solution, which works in 100% of cases. emacs is a subject of "lisp curse"[1]: it is too configurable for people to make it usable. People just hack around to make it work for them, and no one tries to make reasonable defaults, because when you set up text editor and ready to make reasonable defaults your editor already is configured and you personally doesn't need no defaults. [1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
random_cynic 6y ago
>This view is obviously biased against Emacs,.. Yeah, no bias in your comment. This is the kind of gatekeeping that is keeping Emacs from being popular. All of what you said works great in a "blog" and social media to get upvotes and +1s, but not in real world. > Meanwhile company X will just slot in cookie cutter developer 1 and ask them to use VSCode because they are eager to get the developer to be "productive" on Day 1 for some reason. This is not only insulting but ignorant. Have you looked at how extensible VSCode is and how most of the users are using it before you made your comment? Just because it is great outside the box, does not mean it is not extensible or the users cannot "tune their workflow".

TheSpiceIsLife 6y ago

I’m not a programmer, just a tradesman who’s worn a few different hats over the eons, but I’ve noticed something as I’ve gotten older and lazier: I am equally as unproductive regardless of my setup. My productivity has way more to do with all the other factors at play than it does the fine-tuning of my setup.

michaelmrose 6y ago
In order to be more productive of 10s of thousands of hours one only needs to be slightly more productive to justify spending a handful of hours. 1% per 10k hours is worth 100 hours.
- TheSpiceIsLife 6y ago
  Yeah, to some extent, maybe. I appreciate what you’re saying, and I do hate being slowed down in the moment. I’ve got a handcrafted AutoHotKey script and a 22 button gaming mouse fine tuned for 2D CAD / CAM software at work, so while I am definitely in to this sort of customisation... If I’m honest with myself I don’t really get more work done because I end up using the time being unproductive elsewhere. There’s definitely a certain intellectual curiosity-satisfaction to be had from customisation. I’m just not convinced it’s a net time saver in the long run?
  - Torwald 6y ago
    > a certain intellectual curiosity-satisfaction User interface design (UID) and user experience (UX) are interesting topics. Have you ever conducted an oil change at your car or some other minor mechanical task? Wasn't it fun for a moment (at least that one time)? Machines are interesting.
  - TeMPOraL 6y ago
    > because I end up using the time being unproductive elsewhere. Isn't that literally the point? If you can do your task in 10% less time, and then end up spending that 10% procrastinating on HN, then you still win - the task gets done, and you also get to sneak in something nice. And if you find you'd rather spend that time on something else, or doing more work to finish everything faster, you can choose to do so. Optimizing work gives you choice what to do with the time saved; the default may be that you waste it, but now you have options.
    - TheSpiceIsLife 6y ago
      > Isn't that literally the point? Ah, yep, you might have a point there! Dunno how I missed that. Seems obvious now.
deleted 6y ago
[deleted]

smt88 6y ago

> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. I've been writing software for ~24 years, and I can understand the need for this in the past. Now, I just don't get it. What are emacs users customizing so intensely that no other environment can match it? I've found that JetBrains IDEs with a few plugins do 100% of what I want, including some really advanced refactoring and useful GUI integration with CLI hinters/linters. VS Code takes more setup, but it's similar. The level of customization that emacs supports seems unnecessary to me. Can you talk about a few use cases where emacs is just better than an IDE could be?

Reelin 6y ago
> Can you talk about a few use cases where emacs is just better than an IDE could be? I don't use Emacs at present (Neovim instead), but I find TTY based programs to be genuinely more productive and flexible once you make it past the initial learning curve. Using tmux and ssh to seamlessly float between devices with an ongoing complex editing session immediately comes to mind. I've also used both Eclipse and Visual Studio at different times and distinctly recall what I can only describe as lumbering startup times. Ranger via ssh is often much more straightforward to use (for basic operations and browsing) than trying to click through a bunch of menus and sort out network mounting issues. Neovim does lack advanced refactoring tools out of the box, and I've never gone looking so I can't comment. I suspect Language Server Protocol may change that in the near future though. Regarding the possibilities afforded by the sheer level of customization, vim-fugitive comes to mind though I'm sure there are better examples. (https://github.com/tpope/vim-fugitive https://github.com/tpope/vim-fugitive)
- alfiedotwtf 6y ago
  A +1 here for your comment... I have multiple machines, running Docker, running multiple tux sessions, for different projects. I can’t even begin to think how I’d pick up where I left off when switching between projects if I wasn’t using Vim

pjmlp 6y ago

> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. In most jobs I worked for, taking files home from employer computers would be stealing from security point of view no matter what their contents are. So it means that one has to create those configurations from scratch every single time in each new job.

disgruntledphd2 6y ago
It depends on the job. Certainly you can't add any company-specific tools to your overall init file. However, most of the stuff I do isn't that specific so I have all my customisations in a git repo that I pull from github to whatever machine I'm working on.

shultays 6y ago

I think most emacs user are overestimating the gain they are having by mastering art of emacs. Sure, it sounds useful to copy every 5th character in all lines that fits a certain regular expression but how many times you actually need it on your active development time and how much time you lose by doing that manually or using more traditional tools? The coding is mostly typing and debugging. Visual studio (most ides really) is good enough at that. And to be honest emacs/vim complicates the typing part.

bitwize 6y ago
> Visual studio (most ides really) is good enough at that. No. It's not. Emacs's electric-indent is so close to the Right Thing when you're coding it's incredible -- getting almost perfectly formatted code as you type. Other editors have autoindent, but it never seems to do the right thing. Other editors also see fit to insert closing brackets/parens/quotes, and then miss detecting when I typed the closing punctuation so now I have three brackets/parens/quotes. It throws me off. Just highlight the opening punctuation mark when I close it, the way Emacs (and vim) does. I've given Visual Studio Code a chance. Lots of chances really. Each time I find myself struggling with it more than I should, and needing that Emacs flexibility much more than I anticipated going in. Initially I feel more productive, but the more I worked with it the more it gets in the way, inducing friction and slowing me down. And then I want Emacs back.

ordu 6y ago

> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. I'm using emacs for 15 years, and it doesn't work for me. When I noticed things I'm doing often, I already have a habit of doing these things by this way. So if I wrote an elisp-function to automate things, I wouldn't use it, because my unique way doesn't include this function. I'm trying to find a courage to migrate from emacs to some other IDE, where everything already configured, where I could create new habits relying on automation. You know, like use syntax-aware indexing software instead of "<f9> find . -name *.[ch] -exec grep -Hn something {} \; <enter>". I tried etags, but it doesn't work often enough. So my unique way is to simplify workflow and start with find/grep solution, which works in 100% of cases. emacs is a subject of "lisp curse"[1]: it is too configurable for people to make it usable. People just hack around to make it work for them, and no one tries to make reasonable defaults, because when you set up text editor and ready to make reasonable defaults your editor already is configured and you personally doesn't need no defaults. [1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

random_cynic 6y ago

>This view is obviously biased against Emacs,.. Yeah, no bias in your comment. This is the kind of gatekeeping that is keeping Emacs from being popular. All of what you said works great in a "blog" and social media to get upvotes and +1s, but not in real world. > Meanwhile company X will just slot in cookie cutter developer 1 and ask them to use VSCode because they are eager to get the developer to be "productive" on Day 1 for some reason. This is not only insulting but ignorant. Have you looked at how extensible VSCode is and how most of the users are using it before you made your comment? Just because it is great outside the box, does not mean it is not extensible or the users cannot "tune their workflow".