Hacker News Reader

Comment by enbugger | Hacker News Reader

First I thought that emacs/vim are about productivity. You invest some time to learn its concepts and train muscle memory. In the end of it turned out that you have to forget about spending weekends away from your PC. Not much time was actually saved. My conclusion from all this: this is just another way of doing things with no huge benefits but with bigger portion of loses (at least because this is not mainstream).

View on HN

More like someone who works on their own car. Yeah, they lose the occasional weekend to the maintenance, but they love that they've had the same car for 35 years.

However with Emacs, there are a few thousand other people working on the car too, so despite the fact it's the volkswagen beetle you bought in 1972 and your butt shape is indelibly formed in the cockpit, it has _also_ got electric power train, full self driving and JATOs. :)

I used Emacs every day for 28 years. Until I got really tired of having to put it up on the jacks, as it were, for a weekend every now and then. In order to deal with the fact that everyone who works on Emacs seems to think everyone else is just as enthusiastic as them about spending their weekends fiddling with Emacs.

It isn't for me. At least not anymore.

Dealing with Emacs is a lot like dealing with software written in Python: probably great if you really like going trough long descriptions of how to get something to work. Not so great if you are more concerned with using the tools rather than fiddling with the tools.

The main advantage of encountered is that it doesn't go away.

I've been in contexts where I can't use vscode and I've been in contexts where I can't use intelliJ and so on. The contexts where I can't use emacs (specifically, emacs configured to my preferences) are thin on the ground.

It's a space alien user interface and software abstraction relative to most out there, but the payoff is I never have to put it down.

In what context can you use Emacs but not another editor?

When I'm on shell only and can't bring up an X session for a GUI.

This scenario is fortunately pretty rare these days, especially since vscode supports remote editing, but it still happens from time to time and I can still resolve the issue by just dropping emacs on the target machine and working with it in terminal mode. And vscode is a relatively new option here; If I cast the bones, I predict it will be around for awhile.

In that scenario you can often use Tramp - run Emacs locally and let it use ssh and scp to modify the files on the target system. Does the VS Code remote editing require some kind of server component on the remote system or does it manage it through ssh and shell commands?

Thankfully the cases where the only available editor is /usr/ucb/vi are starting to get rare.

I'm well-familiar with Tramp and love it dearly.

It has several does-not-play-well failure modes that vscode remote doesn't. My favorite is that if I have an ssh out and the session goes down, then (in a way not unlike how a terminal ssh'd out will act if the session goes dead) emacs will just freeze. But apart from those, it's super-great and I do love being able to just treat some random data on some random server or user as a buffer and bring to bear on it everything you can hit a buffer with. That decontextualization, that fitting of one abstraction (the buffer) to so many contexts, is one of the best things about emacs.

Yes, vscode does what it does by installing a remote on the target machine and operating from there.

I rarely see Emacs freeze even with Tramp, but admittedly I rarely see broken connections. I think in that case VS Code will throw up a modal dialog telling you to reload the window, and after reloading you have the option to sever the connection.

For me the main problem with Tramp is the slowness - opening and saving files takes just a tiny bit too long. I'm sure VS Code's approach with a remote server can be faster.

Use helm-M-x and which-key, and avoid anything but use-package and customize. You don't have to eat the muscle-memory elephant all at once.

Or just install spacemacs and get a lot of that set up for you for free, plus a bunch of other cool stuff.

Spacemacs hinders your growth with Emacs over the long run. It hides Emacs internals from you and jumps through a lot of hoops to make Emacs feel modern. But the beauty is skin-deep and the second you start wanting something off-script, you'll find it getting in your way, with online threads and such catering towards vanilla rather than frameworks.

I disagree 100%. There is literally nothing you can do within init.el that you can't do within `.spacemacs`, and you will rarely have to venture outside of `dotspacemacs/user-config ()` except to add layers or packages to the appropriate config variables so they can be installed automatically for you.

I've been using emacs for over 10 years and had zero issues with making the transition. On the contrary, it's simplified my emacs life quite a bit. The only thing I have not been able to get working is `eaf`, but that's clearly not the fault of spacemacs.

Of course there isn't. It's all elisp under the hood. Realize though that you started with vanilla and moved to Spacemacs. Most people are going to do it the other way around. Start with Spacemacs and you're guaranteeing yourself a rough time, because you won't have the understanding of vanilla you need in order to customize it. I wound up dumping both Spacemacs and Doom once I finished reading Mastering Emacs. I may move back in the future but for now I'm much happier with a simpler system.

Yeah, that couple hours a year is a real killer.

Reply on news.ycombinator.com