5 ms·

I would expect an experienced emacs user to have a config already that more or less "works". Was this a junior developer that just decided to start using emacs

I would expect an experienced emacs user to have a config already that more or less "works". Was this a junior developer that just decided to start using emacs one day? I'm not an emacs person myself, but every emacs person I have ever met already has it setup and customized and just brings their config. A new dev starting with emacs on a new job... just sounds like a bad recipe and misunderstood priorities.

jjoonathan 6y ago
> already has it setup and customized and just brings their config You might not have seen it happen, but if my experience was any indication, they spent a lot of time crafting that config file. I've spent less total time configuring TextMate, Sublime, IntelliJ, Atom, Jupyter, VS Code, and PyCharm than I spent back in the day trying to learn emacs lisp and get the emacs plugins for ObjC syntax highlighting and fuzzy filename matching to play nicely with each other. Meanwhile, each of those GUI editors brought considerably more impactful unique day-to-day functionality to the table than emacs ever did.
- Scarbutt 6y ago
  You had to spend time learn a new set of keybindings for each one though, for editing and interacting with the interface.
  - jjoonathan 6y ago
    Not really. The most common keybindings of GUI text editing have largely converged, and those that haven't collectively account for similar total complexity to, say, basic file/buffer management and movement in emacs. Yes, the life of an editor nomad sometimes involves hitting the wrong key to build or occasionally forgetting which modifiers trigger block select, but those adjustment pains are typically overshadowed by the joys of high-priority platform integration that works straight out of the box, and they're downright tiny in comparison to the pain I used to experience getting half-assed platform support up and limping in emacs.
- josteink 6y ago
  > You might not have seen it happen, but if my experience was any indication, they spent a lot of time crafting that config file. Yes. I've spent 10 years crafting this file I'm using now. One bit at a time, every time I found something which could improve my productivity and editing experience. And I can now bring that with me anywhere at literally zero cost. I'm not sure why anyone would frame that as a bad thing?
chipotle_coyote 6y ago
While I think you're right on the whole here about "Emacs people," but you did an interesting thing in the first sentence: you contrasted experienced Emacs user with junior developer. And I think that actually points to a problem: people who are experienced developers but not experienced Emacs users are going to be in much the same position as the OP's description. While I know the basics of Emacs, every time I try to get serious with it and make it my One True Editor, I end up spending days screwing around with packages and configuration files to try to figure out how to have similar functionality to what I get either out of the box or with fairly minimal effort in arguably lesser editors. I'm sure Emacs can do all of what I need and nearly all of what I want, but most of the time I'm damned if I can figure out how to get there from where I'm starting. If I was really going to try to give advice on how to make Emacs more popular, it'd center around the package/extension system. It's great that it has package repositories and a built-in management system now, and the documentation for the core editor is terrific... but the documentation for packages is wildly variable, and what's worse, packages interact with one another, depend on one another, and/or conflict with one another in ways that are just utterly mystifying to a newbie. I don't care about making Emacs "pretty," and while it'd be nice if it used less weird terminology by today's standards, I can deal with it. What I want is sane defaults and good guidance. Spacemacs' concept of layers -- where I can just say "I would like you to install and enable all the crap that lets me smartly edit PHP files, please" -- is absolutely onto something, although I would still argue that it might need to offer a little less choice by default. Don't make me choose whether I want Helm or Ivy because I have no idea, and for God's sake, enable sensible layers/packages by default: assume that yes, I do want autocompletion and git integration and such. If you must, let me click a button to choose between "batteries included" and "advanced" configuration. This is stuff that mainline Emacs should be doing. And, actually, that's one other thing Emacs could stand to do better: learn from VS Code's configuration system that lets you use dropdowns and checkboxes and simple text fields for nearly everything, and has a button to go into the configuration files when you need it. Yes, I know Emacs has a text-based UI for configuration, too. I've used it. It's bad. Okay? It's just bad. The controls are non-standard and weird, the organization is utterly mystifying to someone who doesn't already understand Emacsology, just... no. Start over. As for me, well, when Spacemacs moves the LSP layer to its non-development branch, I'll probably give it a try again. Until then, I'm probably gonna keep doing my technical writing in BBEdit and my coding in Visual Code. (I'm probably gonna keep doing my technical writing in BBEdit until I die, but that's a different post.)

jjoonathan 6y ago

> already has it setup and customized and just brings their config You might not have seen it happen, but if my experience was any indication, they spent a lot of time crafting that config file. I've spent less total time configuring TextMate, Sublime, IntelliJ, Atom, Jupyter, VS Code, and PyCharm than I spent back in the day trying to learn emacs lisp and get the emacs plugins for ObjC syntax highlighting and fuzzy filename matching to play nicely with each other. Meanwhile, each of those GUI editors brought considerably more impactful unique day-to-day functionality to the table than emacs ever did.

Scarbutt 6y ago
You had to spend time learn a new set of keybindings for each one though, for editing and interacting with the interface.
- jjoonathan 6y ago
  Not really. The most common keybindings of GUI text editing have largely converged, and those that haven't collectively account for similar total complexity to, say, basic file/buffer management and movement in emacs. Yes, the life of an editor nomad sometimes involves hitting the wrong key to build or occasionally forgetting which modifiers trigger block select, but those adjustment pains are typically overshadowed by the joys of high-priority platform integration that works straight out of the box, and they're downright tiny in comparison to the pain I used to experience getting half-assed platform support up and limping in emacs.
josteink 6y ago
> You might not have seen it happen, but if my experience was any indication, they spent a lot of time crafting that config file. Yes. I've spent 10 years crafting this file I'm using now. One bit at a time, every time I found something which could improve my productivity and editing experience. And I can now bring that with me anywhere at literally zero cost. I'm not sure why anyone would frame that as a bad thing?

chipotle_coyote 6y ago

While I think you're right on the whole here about "Emacs people," but you did an interesting thing in the first sentence: you contrasted experienced Emacs user with junior developer. And I think that actually points to a problem: people who are experienced developers but not experienced Emacs users are going to be in much the same position as the OP's description. While I know the basics of Emacs, every time I try to get serious with it and make it my One True Editor, I end up spending days screwing around with packages and configuration files to try to figure out how to have similar functionality to what I get either out of the box or with fairly minimal effort in arguably lesser editors. I'm sure Emacs can do all of what I need and nearly all of what I want, but most of the time I'm damned if I can figure out how to get there from where I'm starting. If I was really going to try to give advice on how to make Emacs more popular, it'd center around the package/extension system. It's great that it has package repositories and a built-in management system now, and the documentation for the core editor is terrific... but the documentation for packages is wildly variable, and what's worse, packages interact with one another, depend on one another, and/or conflict with one another in ways that are just utterly mystifying to a newbie. I don't care about making Emacs "pretty," and while it'd be nice if it used less weird terminology by today's standards, I can deal with it. What I want is sane defaults and good guidance. Spacemacs' concept of layers -- where I can just say "I would like you to install and enable all the crap that lets me smartly edit PHP files, please" -- is absolutely onto something, although I would still argue that it might need to offer a little less choice by default. Don't make me choose whether I want Helm or Ivy because I have no idea, and for God's sake, enable sensible layers/packages by default: assume that yes, I do want autocompletion and git integration and such. If you must, let me click a button to choose between "batteries included" and "advanced" configuration. This is stuff that mainline Emacs should be doing. And, actually, that's one other thing Emacs could stand to do better: learn from VS Code's configuration system that lets you use dropdowns and checkboxes and simple text fields for nearly everything, and has a button to go into the configuration files when you need it. Yes, I know Emacs has a text-based UI for configuration, too. I've used it. It's bad. Okay? It's just bad. The controls are non-standard and weird, the organization is utterly mystifying to someone who doesn't already understand Emacsology, just... no. Start over. As for me, well, when Spacemacs moves the LSP layer to its non-development branch, I'll probably give it a try again. Until then, I'm probably gonna keep doing my technical writing in BBEdit and my coding in Visual Code. (I'm probably gonna keep doing my technical writing in BBEdit until I die, but that's a different post.)