4 ms·

Did we read the same article? The author of the article customized his environment so opening a file no longer froze his editor. I wouldn't classify that eith

by bjeds 6y ago

Did we read the same article? The author of the article customized his environment so opening a file no longer froze his editor. I wouldn't classify that either as "slightly better ergonomics" nor "tinkering" nor "bike shedding". He had the discipline to improve his favorite editor. Good for him. Emacs is obviously a very powerful environment for people who know how to use it. I applaud the author for documenting how he fixed this. The only difference between emacs and many other open source software is here you can easily solve bugs in your config file, instead of filing a pull request or submitting a patch to some git repo. The first you call "tinkering" and look down upon. The other I assume you approve of? But why the double standard?

coldtea 6y ago
>Did we read the same article? I didn't respond to the article, I responded to your particular comment, which seemed to imply that customizing your programming environment in general is something great and necessary. >The author of the article customized his environment so opening a file no longer froze his editor. That doesn't clarify as "customizing my environment" is more like "fixing fundamentally broken shit".
- danShumway 6y ago
  > That doesn't clarify as "customizing my environment" is more like "fixing fundamentally broken shit". I mean, sure, if you define any config change that tangibly results in higher productivity and better performance as a fundamental bugfix instead of a customization, then customizations don't matter. But that seems to be a kind of arbitrary distinction. Just as an analogy: ---- "I lost 30 pounds and fixed a sleep apnea problem when I started paying attention to my diet." "That isn't paying attention to your diet, it's fixing a fundamental health problem. In general, most dieting falls into the category of fads and micromanaging." ---- Aside from your specific definitions about what does and doesn't count as customization, what do you and the OP actually disagree on? Do both of you agree that when changing an Emacs config, I should take into account the ratio of time they'll save and the time I'll lose making them? Do both of you agree that there are changes I can make to an Emacs config that would eventually provide a net benefit in terms of time saved? Is it good that I can make those changes that save me time in the long run? Is it bad if I ignore the cost/benefit analysis of a customization and spend more time messing with configs than actually programming? I don't understand what you're actually arguing about.

by bjeds 6y ago

coldtea 6y ago

>Did we read the same article? I didn't respond to the article, I responded to your particular comment, which seemed to imply that customizing your programming environment in general is something great and necessary. >The author of the article customized his environment so opening a file no longer froze his editor. That doesn't clarify as "customizing my environment" is more like "fixing fundamentally broken shit".

danShumway 6y ago
> That doesn't clarify as "customizing my environment" is more like "fixing fundamentally broken shit". I mean, sure, if you define any config change that tangibly results in higher productivity and better performance as a fundamental bugfix instead of a customization, then customizations don't matter. But that seems to be a kind of arbitrary distinction. Just as an analogy: ---- "I lost 30 pounds and fixed a sleep apnea problem when I started paying attention to my diet." "That isn't paying attention to your diet, it's fixing a fundamental health problem. In general, most dieting falls into the category of fads and micromanaging." ---- Aside from your specific definitions about what does and doesn't count as customization, what do you and the OP actually disagree on? Do both of you agree that when changing an Emacs config, I should take into account the ratio of time they'll save and the time I'll lose making them? Do both of you agree that there are changes I can make to an Emacs config that would eventually provide a net benefit in terms of time saved? Is it good that I can make those changes that save me time in the long run? Is it bad if I ignore the cost/benefit analysis of a customization and spend more time messing with configs than actually programming? I don't understand what you're actually arguing about.