Comment by ilovecaching | Hacker News Reader

Comment by ilovecaching | Hacker News Reader

Parent Full thread

I highly recommend modern Emacs over VSCode. If you don't want to tinker, Emacs has multiple levels of preconfigured distributions like Prelude, Nano, and Doom Emacs that give the same out of the box working experience. Modern Emacs includes all of the great features of VSCode, plus much more. You get things like:

- LSP support for completion, refactoring, listing.

- Tree sitter support for super fast highlighting.

- File supporter just like VSCodes.

- Project management tools.

- Fuzzing finding for everything, including files, commands, and buffers.

- Probably the best git client out there (magit). It's seriously magical.

- Terminals (can pipe terminal contents directly into other buffers).

- DAP mode for debugging, ctags, cscope.

It's all FOSS, worked on by a non-profit foundation and volunteers, it can be used as a GUI or in the terminal, and it's insanely extensible thanks to it being a small C core running a lisp environment. Lisp is easy to learn and fun, and if you don't like lisp there's still a bazillion more packages you can install for extra features.

I'm happy people love Emacs, but it's not remotely close to the same "out of the box experience", and I think it will put people off to claim it does.

I few months ago I spent a week using Doom Emacs (based on a friend's recommendation). It took days to get used to basic functionality (cut/copy/paste/save/etc), and after a week I still couldn't get error highlighting and running tests to work in Rust.

With VSCode, I opened a Rust project and a box popped up saying "hey, want to install the rust plugin", I said yes, it installed (including installing the approriate version of rust-analyzer), and everything worked.

Switched to Doom Emacs about a year or two ago it has been the biggest improvement in my tools as a developer since becoming proficient with the CLI.

That being said there is a bit of a learning curve.

The learning curve can be steep especially if you are used to other keybindings. For vim users, I heard only good things about evil-mode (and it's the default in doom). I personally use default emacs bindings (with a switch between Meta and Ctrl as the Ctrl key is usually poorly located on keyboards).

If you don't use the caps lock, you can easily change it to be another Ctrl key. It's perfectly positioned for regular use, and how often do you really use the caps lock key?

It's great for any application where you use keyboard shortcuts.

This is compelling! But I ended up abandoning Emacs in previous attempts to switch to it. In case anyone can help solve the pain points I remember:

1. Which project management tools do you recommend? (I think I was using Projectile in the past, but from what I recall it left buffers from previous projects open when switching to other projects, which ended up being kind of annoying.)

2. Any advice about automatic whitespace/indentation handling with Emacs?

Ideally I want to have Emacs automatically:

- Use a prettier config if present.

- Fall back to editorconfig if present.

- Infer whitespace from the file if no formatting configs are found.

- Match and auto-format indentation when pasting text.

That's pretty much how it works with VS Code. I really struggled to recreate this in Emacs the last time I tried, and as silly as it sounds it ultimately put me off using Emacs. (I work across a lot of repos with different languages and conventions; with Emacs I had to double-check every commit for whitespace issues, but with VS Code I rarely think about it.)

3. How do you handle long-running processes in Emacs? I struggled to find a way to run multiple build processes in the background and quickly switch between/kill/read output/restart them. (Is M-x compile the right approach, or is there something else?)

4. Is libvterm still the best terminal emulator for Emacs? From VS Code/tmux I'm used to being able to summon multiple terminal instances with different tabs/ splits, and the experience in Emacs felt less good last time I tried to recreate this.

1. project.el and tabspaces

2. I think you'll want to write some elisp for this. I use apheleia though, maybe it does this?

3. async-shell-command or... hmm... there is a emacs binding to a go library for managing async processes I can't recall the name of.

4. vterm is best in the sense of most support for ncurses things. I personally try to use eshell for everything. As far as different tabs/splits emacs should be able to do that. Can you give a specific example of something you had trouble with?

Thanks for these tips! I'll explore tabspaces, apheleia, async-shell-command (and the Go lib) — all of those are new to me.

> Can you give a specific example of something you had trouble with?

I hoped to recreate multiple long-running terminal sessions in splits and tabs, similar to functionality I now use from:

Neovim (plugin): https://github.com/akinsho/toggleterm.nvim

VS Code (built-in): https://code.visualstudio.com/docs/terminal/basics#_managing...

I just found “popper”, which didn't exist the last time I looked. It seems like a pretty close substitute:

https://github.com/karthink/popper

> I hoped to recreate multiple long-running terminal sessions in splits and tabs, similar to functionality I now use from:

> Neovim (plugin): https://github.com/akinsho/toggleterm.nvim

> VS Code (built-in): https://code.visualstudio.com/docs/terminal/basics#_managing...

The example in that vscode link can be replicated in emacs by:

1. having a single buffer open 2. C-x 2 (split-window-below) 3. C-x o (other-buffer) 4. C-x 3 (split-window-right) 5. C-x 3 (split-window-right) 6. C-x + (balance windows)

If that seems unwieldy you can also make a macro to automate such a thing or anything your imagination can come up with. Then any function you make (such as saving that macro to a name) can be bound to a keybinding of your choice.

If that's interesting to you, also see "Keyboard Macros are Misunderstood":

https://www.masteringemacs.org/article/keyboard-macros-are-m...

In fact, if you really want to understand Emacs in addition to replicating your current vscode workflow or even to augment your current workflows you should check out his book that was recently updated for Emacs 28:

https://www.masteringemacs.org/book#free-sample

He typically updates the book pretty quickly, so you'll get any future updates he may make. I still highly recommend the current version after having ready 5 or 6 chapters recently and feeling like I leveled up my own understanding.

Thank you for this — keyboard macros look great, and I'll explore the book to fill in some gaps.

Thanks for suggesting "vterm", I wasn't aware of its existence. I just installed it, it seems to work perfectly!

For #2, I've been pretty happy with dtrt-indent (https://github.com/jscheid/dtrt-indent) for DWIM indentation bouncing between projects.

I have yet to try apheleia, but I wouldn't be surprised if just enabling apheleia, dtrt-indent, electric-indent-mode (a built-in I don't use, but which may cover your indent-on-paste desire), and editorconfig-mode (https://github.com/editorconfig/editorconfig-emacs) in prog-mode-hook just did what you wanted.

>Is libvterm still the best terminal emulator for Emacs? From VS Code/tmux I'm used to being able to summon multiple terminal instances with different tabs/ splits, and the experience in Emacs felt less good last time I tried to recreate this.

vterm is awesome, I recommend using multi-vterm if you want more than one

1.projectile-kill-buffers or the built-in project-kill-buffers will do that for the current project. You could run that before switching projects.

2. https://github.com/radian-software/apheleia

3. There might be a way to do this but I'm not sure. Emacs being inherently single threaded probably makes this difficult. But yes, I use M-x (re)compile.

4. libvterm is the best still imo. You can definitely do multiple instances and there's even different tab modes in Emacs now.

> 3. There might be a way to do this but I'm not sure. Emacs being inherently single threaded probably makes this difficult. But yes, I use M-x (re)compile.

Emacs has zero issue with multiple compilations - they're handled asynchronously. If threading was an issue it would kill Emacs with just one active compilation let alone many. The lack of threading in Emacs is a significant issue, but simultaneously nowhere near as restrictive and troublesome as many people seem to believe.

It's irritating that Emacs inhibits simultaneous compilations by default, but that's literally simply down to buffer naming. Emacs uncompromisingly uses a buffer called "*compilation*" for compiliation and will only run one at a time in a buffer.

There are simple hacks floating around to have compilation create a unique buffer name, then it happily runs as many as you like. Also, `projectile` has the setting `projectile-per-project-compilation-buffer` which enables this by putting the project name in the compilation buffer name.

I do echo the sentiment that it is not an easy out-of-the-box experience, and the learning curve is steep, though this is the sort of configuration that I assume the likes of doom set up by default. But even then, starting with doom is a much more significant endeavor than starting with VS Code.

But once you learn and develop your Emacs set up it becomes a delightful, malleable, and extremely powerful environment that's comfortable like an old leather chair, and where it isn't, you make it just how you want it. Some of us were lucky enough to accumulate proficiency over years and decades starting in a time when there weren't easier options with comparable power.

I love to have people join us and appreciate it, but it's not an easy process to get to the payoff.

Thank you for the kind reply and pointers!

Apheleia in particular was new to me — I don't think it even existed last time I looked. So good to see the Emacs community continuing to thrive and invent.

I use projectile and perspective. Everything is integrated into my Ivy/Counsel and I have simple self documenting shortcuts for everything using General keybindings.

Until I set this up correctly the leftover buffers bothered me. Now it's part of my workflow.

I often have code from two projects side-by-side in split windows. Projectile restricts all of my actions to the appropriate project Autocomplete, code navigation, file search, fuzzy greps, everything uses the buffer's project as context.

With just two key presses I can close all buffers for any open project.

For number 1 I use perspective with projectile.

https://github.com/nex3/perspective-el

https://github.com/bbatsov/persp-projectile

projectile does have a command to kill all buffers from the current project that I regularly use fwiw

For 1, also remember that you can just run multiple copies of emacs for different projects. Nobody says you have to use all the packages that ostensibly solve some problem you have.

3. Can't you launch your compilation (or similar) and then M-x rename-buffer?

EDIT: try `g` for "refresh"/recompile.

Maybe that's just me though, not sure this is an official method.

> 2. Any advice about automatic whitespace/indentation handling with Emacs?

I use prettier-mode and editorconfig-mode. Everything is formatted on save so works well for me.

I recommend dtrt-indent and ws-butler for your whitespace concerns

Were you trying to make your own config, or use something prerolled like Doom?

I started with Doom to discover what features were available/useful to me. Then I built my own config from scratch recreating/borrowing only those features.

I got pretty close apart from the above sticking points. I only moved on when I realised how much time I was spending writing Emacs Lisp to solve my remaining pain points. I miss it, though!

Yes, but what about remote support? That’s the single most thing I miss from VSCode.

I want to run my editor on the local machine so that it can benefit from graphics support and integrate properly with the local windowing system, but I want all heavy lifting (LSP and the like) done on a remote machine.

Yes, I can use Emacs over SSH (which I do now), but it has limitations. Yes, I could forward X11, but it’s pretty terrible to do so from Windows or macOS.

I tried TRAMP in the past, but it didn’t seem to match VSCode’s power at all in this area. Maybe I configured it wrong though, or maybe it has improved. Any thoughts?

> I tried TRAMP in the past, but it didn’t seem to match VSCode’s power at all in this area.

What was missing. I used TRAMP for years and aside from opening the initial file, it was identical to working locally for me. That said I haven't needed to use it in years, and haven't used the remote support in VSCode.

I remember running into a lot of trouble trying to get the thing to just work. There were some issues in trying to use Windows as the client and some stuff in my zshrc also got in the way. I think I was able to me it run more or less, but I gave up at the time.

I’ve recently been getting into Emacs again and have a pretty good setup already, so I’ll have to try TRAMP again.

You can try using emacsserver remotely. I would recommend using SSH proxying instead of messing with emacs over tcp.

Personally I use emacs on a large dev machine running in a container in a terminal emulator. I can work from my iPad Pro, iPhone, MacBook Pro, Windows Desktop, Linux Desktop, or any guest machine by just adding one public key. Terminal Emulators are still just GUI apps and fit into the GUI ecosystem. Modern emulators also have true color support, GPU based rendering, full unicode support, support for custom fonts that add additional graphics, etc. You can make a terminal editor look like something incredibly modern if you want to. I personally don't find any value in that, for me the basic appearance of a terminal editor is less distracting.

The only time I've seen anyone use "emacs server" or "emacsserver" is to refer to the Emacs Lisp needed to make the command emacsclient (the analog to VS Code's "code" command or TextMate's "mate" command) work.

Correct me if I am wrong, but I believe you are using it to refer to running Emacs remotely without a GUI (i.e., with only a terminal emulator as the UI) even though the person you are replying to specifically stated, "I want to run my editor on the local machine so that it can benefit from graphics support and integrate properly with the local windowing system."

I am writing this to prevent readers of your comment from ending up more confused than they were before they started reading this thread.

You can run an emacs daemon[0] and connect to it from clients both local and remote, including having multiple clients connected to the same daemon and editing the same file with total synchronization built in, you see not only the changes in realntime but the other client's cursors making the changes, for the masochists that enjoy pair programming.

And yes you can run the client using the gui emacs not only terminal emacs.

I assume that's what he is talking about.

[0]https://www.emacswiki.org/emacs/EmacsAsDaemon#h5o-13

Your comment is confusing in the same way as the the other guy's is. In fact it is worse.

None of the machinery you describe can be used for anything except specifying files (and line numbers and column numbers) to be visited. An emacs user still needs some way of interacting with the visited file, e.g., a terminal emulator or an X server. This "Emacs server" does not help with that. It's another example of Emacs using unusual terminology!

Have you actually used Emacs or do you just enjoy making pendantic confusing replies?

do you any tips on how to set this up? or maybe point me in the right direction?

I tried to use tramp based setup, but ran into many edge cases. Even popular libraries like flycheck doesn't support tramp very well. Eventually I found mosh and that settled the problem. Mosh + iterm2 + terminal emacs[1] combination works very well. Except a few missing features (fringe, variable font size/multiple fonts), nearly everything else works well.

1: https://ananthakumaran.in/2021/07/31/emacs-remote.html

> I tried to use tramp based setup, but ran into many edge cases. Even popular libraries like flycheck doesn't support tramp very well.

Try using more "core" libraries like flymake that accounted for (or seem to) tramp from the start.

X forwarding is always an option.

I'm at an organization where our dev machines are in the cloud. Most folks are indeed using VSCode remotely, but I'm happy with emacs.

The combo that works for me (on MacOs locally) is daemon mode and X11 forwarding...but using x2Go instead of vanilla "ssh -X". I end up with XQuartz windows that behave (mostly*) like other MacOS windows and pretty good performance.

If I'm at cafe or somewhere with spotty internet, I'll forgo the X stuff and just use mosh and text only emacs, but I pretty much never do that anymore.

(* mostly, meaning that for some reason tools like divvy and other things that manipulate/resize windows just don't work with X Quartz windows)

> Yes, I can use Emacs over SSH (which I do now), but it has limitations. Yes, I could forward X11, but it’s pretty terrible to do so from Windows or macOS.

Which limitations (that matter)? Maybe I was just too used to vim - everybody is saying use the graphical edition of emacs, but I don't really care. mosh + emacs works great for me.

One thing that helped a lot is making the tmux clipboard transfer to your local computer.

I use tramp on a devcontainer daily FWIW.

What languages? I've struggled to get it working with Ruby (specifically with robe) and it's the one thing that keeps me in VSCode for work.

I can say that Haskell and haskell-language-server work with eglot in a devcontainer.

I've been using emacs for many years but honestly I can't recommend it for new users.

Ignore all the features and look at the speed. It's slow, especially when using all those nice features. Big buffers are laggy. LSP in particular is slow.

Honestly it's bad enough that I think I'm gonna start looking into neovim. I'll miss the macro support but it's getting harder and harder to excuse the overall slowness.

Reply on news.ycombinator.com