4 ms·

Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their

by k33n 7y ago

Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more configuring it, reconfiguring it, refactoring my configuration, and other things that wasted my time I'm not going to make the world a better place by configuring my editor. I'm going to do it by shipping code. I'm a recovering terminal junkie. I had a problem. I was bored with my work so I wanted to challenge myself. Maybe I even enjoyed procrastinating a little.

bachmeier 7y ago
Spending time on your tools instead of your work is not a sign that you need to change your tools - it's a sign that your work sucks.
- dkarl 7y ago
  Yeah, I don't understand this theory that if your tools are at all configurable or learnable you'll be compelled to waste time yak-shaving them. I think you're right that the problem is with the stuff you're NOT doing. I use emacs every day, but there's a ton of stuff I don't use emacs for because the investment to become proficient in the emacs solution won't pay off in my circumstances. There's a middle way between writing code in nano and getting lost trying to program emacs to do your job for you. As with everything (programming languages, build tools, optimization, etc.) there are people who go much further into the rabbit hole of text editors than you could practically justify in your own work, but 1) they might be doing it for some intrinsic satisfaction rather than out of delusion, and 2) thank goodness for people like that, because they build and improve a lot of the software we benefit from.
- falcolas 7y ago
  Or that your tools (as currently configured) are insufficient to the task of doing your work. If you wonder why a woodworker hasn't finished the chair, a completely valid answer is "all the edged tools you gave me were dull".
SirensOfTitan 7y ago
So if you’re not making the world a better place you’re wasting your time? Play is supremely important in almost any activity. Not only is there incredible work insight to be found in activity without goals, but play is fun and good for you.
- bovermyer 7y ago
  This is a very important idea that doesn't get enough attention.
- kashyapc 7y ago
  On the importance of "play"— From one of the books I'm currently reading (Blueprint, The evolutionary Origins of a Good Society, by Nicholas Christakis — itself a great read), I learnt of an interesting book reference: Homo Ludens: A Study of the Play-Element in Culture (1938). The abstract sounds promising: "[...] With cross-cultural examples from the humanities, business, and politics, Huizinga examines play in all its diverse guises—as it relates to language, law, war, knowledge, poetry, myth, philosophy, art, and much more. As he writes, “Civilization is, in its earliest phases, played. It does not come from play like a baby detaching itself from the womb: it arises in and as play, and never leaves it.” [...] Starting with Plato, Huizinga traces the contribution of “man the player” through the Middle Ages, the Renaissance, and early modern world. [...]" [*] https://www.amazon.com/Homo-Ludens-Study-Play-Element-Culture/dp/1621389995 https://www.amazon.com/Homo-Ludens-Study-Play-Element-Cultur...
- cuddlybacon 7y ago
  Is tweaking your emacs config play? Or is it work? When I was younger, it felt more like play. In my late 20's it became work.
jimbokun 7y ago
But I mean, that's not Emacs fault?
- falcolas 7y ago
  It very well could be. Attempting to either adapt yourself to emacs, or emacs to you, can take a long time, and may also fail. Not to mention that, as much as I love emacs and other free software, bugs in your tools can absolutely destroy a day. The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.
  - jimbokun 7y ago
    > The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor. This can happen just as easily by installing a buggy plugin in any other IDE. I love IntelliJ, but have definitely lost time trying to figure out how to make something work or configure it to my liking.
    - falcolas 7y ago
      It can. The thing I like about some of the other IDEs though is that it doesn't tear down the entire process; the plugins are sandboxed. Is this possible in Emacs? I'd be shocked if the answer is no. But most major modes I've personally interacted with are not.
_wolfie_ 7y ago
> I'm not going to make the world a better place by configuring my editor I think this covers work of most programmers. Doesn't matter if time is spent writing editor config or production code...
dkarl 7y ago
> I'm a recovering terminal junkie. I had a problem. Maybe you went too far, but I think there's also a widespread problem with people not going far enough. I know smart people who have been working in the industry for over a decade who don't bother learning basic text manipulation tools because they look down on the shell and assume they're going to have to switch text editors every few years anyway. Sublime Text, BBEdit, Atom, VSCode -- you only get two or three years with each one, so there's no point learning more than delete, copy, paste, search/replace in file, jump to file, jump to symbol, and if you're really fancy, search/replace in multiple files. But you can't get past how much of everything we work on is text, no matter how lofty the abstractions it encodes. Munging text takes an inordinate amount of our time. I have seen senior engineers spend an hour writing and debugging scripts to make changes in a big file that they could have made in minutes by using regex-replace or recording a keyboard macro in their editor. Same with basic sed and awk usage. If they can do it by hand in under ten minutes they'll do it that way; otherwise they'll file a ticket and write a script. I have seen senior engineers painstaking picking through multi-kB json blobs adding line breaks in strategic places to make them readable. ("I used to use this one web site that reformatted JSON for you, but then it shut down, and I always felt nervous about posting internal data to random web sites anyway.") That's an extreme case, but I've seen it more than once, and it's tragic. I agree it's hard to know ahead of time where to invest your time. One of the best engineers I ever worked with once told me, "The best thing that ever happened to me was that in undergrad I was working for a professor who had all these crazy awk scripts. I spent a whole semester using awk basically every day, even though I hated it." That impressed me —- this was a guy of very impressive theoretical background and incredible ability to design complex systems that worked in simple, reliable ways, and he was talking to me about awk? But it didn't impress me enough, because it was another five years before it sunk in that over the course of my career I had scrolled past an awful lot of simple one or two line awk solutions (on, e.g., Stack Overflow) to get to the solutions I could comprehend -- which were always much more complicated. When considering how to spend your time, I don't think you should worry about the pits you might fall into. I think you should look at the positive possibilities, the positive possibilities, and try to achieve them. It's possible to be very productive in the terminal and in your editor or IDE without going down too many rabbit holes.
kabdib 7y ago
I've been using Emacs for 40 years. My .emacs file is 59 lines long. Most of the customizations turn off features have been added (menu bars and so forth), or that disable "helpful brain damage" that simply got in the way. I've spent 2-3 hours over the last decade tweaking things.
- elwell 7y ago
  At the risk of adding to your 2-3 hours, you might want to check out Key Chord [0] (if you don't use it already) for some low-hanging fruit. [0] - https://www.emacswiki.org/emacs/KeyChord https://www.emacswiki.org/emacs/KeyChord
- downerending 7y ago
  Same. It's a bit like Dvorak. Yes, in theory you could make your life 10% better by carefully customizing, but there's also great value in just sticking with the default for the most part. You can sit down anywhere and everything just works.
dfox 7y ago
My .emacs on this machine is almost literally this: (custom-set-variables '(indent-tabs-mode nil) '(inhibit-startup-screen t) '(menu-bar-mode nil) '(show-paren-mode t) '(tool-bar-mode nil)) On my home computer I have somewhat more involved .emacs, but apart from the above (and huge list of totally random variables picked up by customize-save-customized since 2003) it consists of long-irrelevant compatibility hacks and somewhat complex logic for creating correctly sized frames on additional X displays (which I stopped really using when I got 4k monitor)

by k33n 7y ago

bachmeier 7y ago

Spending time on your tools instead of your work is not a sign that you need to change your tools - it's a sign that your work sucks.

dkarl 7y ago
Yeah, I don't understand this theory that if your tools are at all configurable or learnable you'll be compelled to waste time yak-shaving them. I think you're right that the problem is with the stuff you're NOT doing. I use emacs every day, but there's a ton of stuff I don't use emacs for because the investment to become proficient in the emacs solution won't pay off in my circumstances. There's a middle way between writing code in nano and getting lost trying to program emacs to do your job for you. As with everything (programming languages, build tools, optimization, etc.) there are people who go much further into the rabbit hole of text editors than you could practically justify in your own work, but 1) they might be doing it for some intrinsic satisfaction rather than out of delusion, and 2) thank goodness for people like that, because they build and improve a lot of the software we benefit from.
falcolas 7y ago
Or that your tools (as currently configured) are insufficient to the task of doing your work. If you wonder why a woodworker hasn't finished the chair, a completely valid answer is "all the edged tools you gave me were dull".

SirensOfTitan 7y ago

So if you’re not making the world a better place you’re wasting your time? Play is supremely important in almost any activity. Not only is there incredible work insight to be found in activity without goals, but play is fun and good for you.

bovermyer 7y ago
This is a very important idea that doesn't get enough attention.
kashyapc 7y ago
On the importance of "play"— From one of the books I'm currently reading (Blueprint, The evolutionary Origins of a Good Society, by Nicholas Christakis — itself a great read), I learnt of an interesting book reference: Homo Ludens: A Study of the Play-Element in Culture (1938). The abstract sounds promising: "[...] With cross-cultural examples from the humanities, business, and politics, Huizinga examines play in all its diverse guises—as it relates to language, law, war, knowledge, poetry, myth, philosophy, art, and much more. As he writes, “Civilization is, in its earliest phases, played. It does not come from play like a baby detaching itself from the womb: it arises in and as play, and never leaves it.” [...] Starting with Plato, Huizinga traces the contribution of “man the player” through the Middle Ages, the Renaissance, and early modern world. [...]" [*] https://www.amazon.com/Homo-Ludens-Study-Play-Element-Culture/dp/1621389995 https://www.amazon.com/Homo-Ludens-Study-Play-Element-Cultur...
cuddlybacon 7y ago
Is tweaking your emacs config play? Or is it work? When I was younger, it felt more like play. In my late 20's it became work.

jimbokun 7y ago

But I mean, that's not Emacs fault?

falcolas 7y ago
It very well could be. Attempting to either adapt yourself to emacs, or emacs to you, can take a long time, and may also fail. Not to mention that, as much as I love emacs and other free software, bugs in your tools can absolutely destroy a day. The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.
- jimbokun 7y ago
  > The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor. This can happen just as easily by installing a buggy plugin in any other IDE. I love IntelliJ, but have definitely lost time trying to figure out how to make something work or configure it to my liking.
  - falcolas 7y ago
    It can. The thing I like about some of the other IDEs though is that it doesn't tear down the entire process; the plugins are sandboxed. Is this possible in Emacs? I'd be shocked if the answer is no. But most major modes I've personally interacted with are not.

_wolfie_ 7y ago

> I'm not going to make the world a better place by configuring my editor I think this covers work of most programmers. Doesn't matter if time is spent writing editor config or production code...

dkarl 7y ago

> I'm a recovering terminal junkie. I had a problem. Maybe you went too far, but I think there's also a widespread problem with people not going far enough. I know smart people who have been working in the industry for over a decade who don't bother learning basic text manipulation tools because they look down on the shell and assume they're going to have to switch text editors every few years anyway. Sublime Text, BBEdit, Atom, VSCode -- you only get two or three years with each one, so there's no point learning more than delete, copy, paste, search/replace in file, jump to file, jump to symbol, and if you're really fancy, search/replace in multiple files. But you can't get past how much of everything we work on is text, no matter how lofty the abstractions it encodes. Munging text takes an inordinate amount of our time. I have seen senior engineers spend an hour writing and debugging scripts to make changes in a big file that they could have made in minutes by using regex-replace or recording a keyboard macro in their editor. Same with basic sed and awk usage. If they can do it by hand in under ten minutes they'll do it that way; otherwise they'll file a ticket and write a script. I have seen senior engineers painstaking picking through multi-kB json blobs adding line breaks in strategic places to make them readable. ("I used to use this one web site that reformatted JSON for you, but then it shut down, and I always felt nervous about posting internal data to random web sites anyway.") That's an extreme case, but I've seen it more than once, and it's tragic. I agree it's hard to know ahead of time where to invest your time. One of the best engineers I ever worked with once told me, "The best thing that ever happened to me was that in undergrad I was working for a professor who had all these crazy awk scripts. I spent a whole semester using awk basically every day, even though I hated it." That impressed me —- this was a guy of very impressive theoretical background and incredible ability to design complex systems that worked in simple, reliable ways, and he was talking to me about awk? But it didn't impress me enough, because it was another five years before it sunk in that over the course of my career I had scrolled past an awful lot of simple one or two line awk solutions (on, e.g., Stack Overflow) to get to the solutions I could comprehend -- which were always much more complicated. When considering how to spend your time, I don't think you should worry about the pits you might fall into. I think you should look at the positive possibilities, the positive possibilities, and try to achieve them. It's possible to be very productive in the terminal and in your editor or IDE without going down too many rabbit holes.

kabdib 7y ago

I've been using Emacs for 40 years. My .emacs file is 59 lines long. Most of the customizations turn off features have been added (menu bars and so forth), or that disable "helpful brain damage" that simply got in the way. I've spent 2-3 hours over the last decade tweaking things.

elwell 7y ago
At the risk of adding to your 2-3 hours, you might want to check out Key Chord [0] (if you don't use it already) for some low-hanging fruit. [0] - https://www.emacswiki.org/emacs/KeyChord https://www.emacswiki.org/emacs/KeyChord
downerending 7y ago
Same. It's a bit like Dvorak. Yes, in theory you could make your life 10% better by carefully customizing, but there's also great value in just sticking with the default for the most part. You can sit down anywhere and everything just works.

dfox 7y ago

My .emacs on this machine is almost literally this: (custom-set-variables '(indent-tabs-mode nil) '(inhibit-startup-screen t) '(menu-bar-mode nil) '(show-paren-mode t) '(tool-bar-mode nil)) On my home computer I have somewhat more involved .emacs, but apart from the above (and huge list of totally random variables picked up by customize-save-customized since 2003) it consists of long-irrelevant compatibility hacks and somewhat complex logic for creating correctly sized frames on additional X displays (which I stopped really using when I got 4k monitor)