> 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.

> 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?

You had to spend time learn a new set of keybindings for each one though, for editing and interacting with the interface.

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.

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.)

> 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.

I’ve used GNU Emacs for twenty years and totally agree. I avoid the customization menus wherever I can.

> As for me, well, when Spacemacs moves the LSP layer to its non-development branch, I'll probably give it a try again

You're doing yourself a discervice for not just using Spacemacs develop branch. It's actually more stable than the master branch.

I use and love Spacemacs, but their branch handling is a major PR fuckup. The last stable version should be phased out now. The develop branch works way better. They should rethink their release model.

True, just think they need to embrace the fast development cadence of develop and just make that master.

Interesting. I switched to the develop branch the other day (yes, just to try to get LSP working!) and ran into some glitch that I didn't have the time to investigate -- a complaint about the .spacemacs file missing a variable or something. I'll probably try again this weekend.

You need to run SPC f e D to do a 3-way merge of your .spacemacs everytime after you upgrade Spacemacs.

As changes to Spacemacs are made, there might need more or less things in the .spacemacs file. So you always need to do a manual merge of the changes.

Thanks for the tip. I had no idea that was a thing -- although it absolutely makes sense, thinking about it!

> I'm probably gonna keep doing my technical writing in BBEdit until I die, but that's a different post.

Please produce that post. Also, why not developing in BBEdit?

BBEdit's indenting and completion engines just aren't as smart as other editors -- I suspect in the latter case they'll have to add LSP support on their own (right now I don't think it can even be added externally because their API doesn't expose the right event hooks), and in the former case, I have a suspicion Bare Bones Software just has a philosophical objection to context-aware indenting. With those objections aside, BBEdit is still pretty good for development.

For the technical writing, I actually wrote a comment here somewhere about that in another post; I'll have to dig it up and turn it into a blog post at some point. But I called it a "fast Swiss army knife for text." Its "open file by name via fuzzy searching" command lets you enter multiple files, its multi-file search window lets you save file filters with meaningful names (and you can save grep patterns the same way, and in BBEdit 13 there's even a "Pattern Playground" that lets you nondestructively test out complex regexes on your current document). Projects get their own persistent scratchpads and Unix worksheets. And, a bit relevant to an Emacs thread, BBEdit has a bit of Emacs-ish keybinding support over and what Mac editors normally do, although it's decidedly not an Emacs emulation layer.

> I have a suspicion Bare Bones Software just has a philosophical objection to context-aware indenting

Yeah, either that or they are procrastinating on some quirk deep in their engine they should rewrite already.