Hacker News Reader

Picking eMacs up as a replacement for VSCode while having to get stuff done is risky. I would venture to say that it’s not realistic as far as your conceptualization. I say this because you venture to ask if the setup process is similar. The answer is a resounding no. VSCode is incredibly easy to “get productive” and eMacs is on the other end of the spectrum.

That being said, if you can work some time into your schedule to learn eMacs, your goal can be realized. (Also, it’s totally worth it.) I was a VSCode user and made some time to learn eMacs exclusively for org mode (possibly eMacs’s coolest feature). Once I was comfortable, I just played around with a dev environment in eMacs (for fun) and loved it so much that I left VSCode.

Thanks for a realistic view! I'm trying out Doom Emacs, per another user's suggestion, and I'm going to try it out for non-code text editing for a while, since I do a lot of that still anyways.

That sounds like a great approach!

I think some of the magic stems from ubiquitous conventions regarding bindings throughout eMacs. If you use evil mode, the conventions become a little murkier. I’d recommend sticking with the vanilla bindings (I haven’t used Doom, so I’m not actually sure if evil mode is default). This is just my two cents. Doom will be a great introduction either way.

I think this is a solid approach.

I found the ebook Mastering Emacs, and the accompanying blog to be extremely useful, even after going through both Spacemacs and Doom Emacs. I may go back to a modal workflow in the future, but for now I'm embracing Emacs' built-in ways of doing things, with a few exceptions.

http://www.masteringemacs.org

You may balk at the $50 pricing, but it gives the most complete picture of how Emacs works than anything else.

To get started with Emacs: (1) install it, either from a package repository or from www.gnu.org/software/emacs; (2) start it up (3) type Control-H t to run the tutorial. Those new to Emacs might prefer to use a customized distribution such as Doom Emacs, but the official Emacs system is quite usable. Don't expect to become an Emacs Master quickly, but doing these 3 steps will get you to the point where you can use Emacs for basic text editing. Emacs comes with lots of documentation, both on the core system and on the many packages it includes, but you can defer reading it until you are comfortable with the basics.

The two hurdles you'll need to overcome are: (1) the antique terminology, so “window” doesn't mean what you might expect it to, and (2) the key bindings, which don't match up with more modern systems. (1) is something you just have to get used to, while (2) is infinitely flexible. A vi user might prefer Doom Emacs or Spacemacs, which come with vi-compatible key-bindings; I'm not aware of something similar for the VSCode user. As you become more comfortable with Emacs, you will be able to make your own key bindings.

Thanks! That actually is what I found in the past, that (1) is hard to get through in order to setup an environment with the cool tools I want to use, and (2) is hard because I'm used to VSCode bindings. I think this time, though, I'm going to stage my use of Emacs because you gave me a good idea:

> doing these 3 steps will get you to the point where you can use Emacs for basic text editing

So, I'm going to replace my use of VSCode for text editing with Emacs for a while to start learning how to work with it, just not code stuff yet, and I'll replace my keybindings in VSCode with Emacs keybindings since VSCode is super easy to find extensions for and there happens to be a few "Emacs keybinding" extensions.

Thanks for the tips, I also didn't know about `Ctrl+H t` and so I'll try that out, too!

I'm actually pretty excited, I've had a ton of issues with VSCode updating the way they do things recently causing my workflows to get fucked up and have to change. I doubt I'll have that issue with Emacs!

The GP gave great advice that, in light of your response, I'll augment.

1 - Sometimes the worst helpers are the enthusiastic fans, not just with bands but with software. Most emacs advice starts by talking about customization. The GP was smart not to: just get comfortable with the model of emacs: a modeless editor. c-f goes forward a character, m-f a word. In code: c-f forward a character, m-f a symbol, c-m-f a structure (depends on the language).

You can always type c-H (^H) at any time for help. It's context-sensitive so if you're typing a long command (m-x find file) it will show you the completions. If you can't remember a command c-H a (apropos) will show you matches. etc. All explained when you start with c-H t

All of the stuff above has been true for more than 40 years. A lot of rough edges have been knocked off over that time! Even back then people who claimed that they "couldn't do anything with a computer" were writing documents with Emacs, even writing macros and such.

For more modern times: you'll find in most programming languages, markdown, etc syntax highlighting is automatic.

Once you are comfortable editing text or code, you can see how to add, say, LSP support, or investigating how to compile your code and why that's easier in Emacs, and just incrementally make your environment more comfortable and powerful. I've been using Emacs since 1978 (when it was written in TECO, not a form of Lisp) and still I learn something new every week or so.

Remember that "EMACS" stands for "Emacs Makes All Computing Simple"

Before you actually dive into coding in Emacs may I suggest to do the following:

1) Get yourself a copy of https://www.masteringemacs.org/ and read it. That gives you a very good overview on the design philosophy of Emacs and many practical tips.

2) Explore vanilla Emacs a little bit. Run the built-in tutorial. Explore Emacs's customization UI. Play tetris.

3) Familiarize yourself with how you install Emacs packages from ELPA and MELPA. On your first steps you can use Emacs' built-in UI. But, ideally, you want to learn "use-package.el" as quickly as possible because that will simplify your configuration a lot.

Coming from VScode you might feel a little bit overwhelmed at this point as you will be starting to use a Lisp macro routinely (!) to install editor extensions. Check out the "Emacs from scratch" series on YouTube for a helpful guide.

4) What programming languages are you using? For React projects you might need to use "webmode.el" which is not built-in. Similar situation with Clojure or Rust. If you want more convenience, you also might want to take a look on "lsp-mode.el" that adds more code introspection features. It is not crazily complicated to install and setup but definitely not beginner friendly.

5) Try to identify your most important extensions you are using right now in VScode. What are the features you cannot live without? Then embark on a google search what the most suitable replacements are in Emacs. For example, VSCode's "Restclient" extensions is paralleled by Emacs' "restclient.el" and it works quite well (if you use it together with "restclient-jq.el" that is).

6) For your dev work flow, checkout Emacs' built-in "compile-mode" (C-l) -- you can paste any shell command in there that will compile your code, run tests or synchronize with a remote dev server (everything that goes inside a bash script). Line errors will be clickable in the output window and help you jump in the offending code line. It's simple and effective. This will make you stop using the shell too often.

7) I recommend installing "which-key.el" which makes Emacs' display a cheat sheet of possible keyboard combos upon hitting control keys (after some delay). This way you'll learn keyboard commands more quickly.

8) However, don't let anyone tell you what the right way of using Emacs is. If you find the mouse menus convenient, by all means use them and don't listen to people who turn off the menu bar. (I even added a custom menu for Emacs modes I happen to use sometimes but not everyday.) Use CUA mode if you are used to "C-c C-v". Don't use the terminal version of Emacs. Ignore the extremists. However, definitely check out "magit.el" for version control.

The way I did it was by not using it for my entire workflow right away. The trojan horse for me was org-mode. Doom Emacs got me started in what felt to be a more modern UX, and I used org-mode not for coding outright, but for note taking and personal project management. After a while, I started to use org-mode's built in ability to run code via org-babel to experiment with ideas in code. Eventually I was comfortable enough that I just started using it to code some times instead of VS Code, because I was already there. I still dual-use VS Code and Emacs because VS Code is still better at some things (working with files on remote server is still kinda slow via TRAMP some times) but I'm about 85% in Emacs now, since I like it better for text traversal, org-mode has become more integrated into my workflow with things like tangle, and I like magit better than VS Code's built-in git interface.

TRAMP is generally performant enough with vanilla Emacs, but there are plenty of popular packages that utterly tank TRAMP performance. The big culprit I’ve personally found was helm. It made TRAMP unusable. You may also need to deal with some finnicky settings both in Emacs and in your remote shell to get it running satisfactorily.

I totally agree though that VS Code has a way better out or the box remote coding experience.

You can use the TTY emacs over SSH (or MOSH) without TRAMP. It only transmits the terminal display so it’s fast regardless of third-party extensions. VS Code remote is actually a negative for me, as it needs fast, stable connections and consumes a lot of RAM on the remote machine.

Treat it like a game for a while. Don't even try to be productive, just play with it and see how the pieces fit together.

That's pretty much my whole approach to life

I totally get that, I've recently started on a toy programming project that has literally no purpose other than to play around, and it's great! It's such a breath of fresh air instead of working on actual work.

Beats stressing out about imaginary money on a race to kill the planet.

> How do I get started using Emacs, if I wanted to use this awesome-sounding tool, while still being friendly to the fact that I have to get stuff done and still need the tools I mentioned above?

Only use the new system on Friday afternoons or whenever your typical slow periods or lulls happen until you get used to it.

If you plan to customize your workflow and extend your system I recommend:

https://github.com/SystemCrafters/crafted-emacs

If you want more out of the box, but harder to debug and extend I'd recommend:

https://github.com/doomemacs/doomemacs (you can use vanilla or vim keybindings)

In either case I'll echo the user recommending Mastering emacs.

Don't forget to check out the MELPA (melpa.org) repository, which has a staggering array of packages for Emacs. If people do something on computers, chances are someone does it in Emacs and there's a package on MELPA to support it.

Also, the road to Emacs proficiency will be a journey, and you'll want to think about Emacs as something you'll gradually tinker with and tweak to get to a set up and understanding that is satisfying. It's not shiny nor whiz-bang by any means, but path through the learning curve can be extremely rewarding.

Thanks for that link, very useful for me to be able to find that stuff in one place. I want to treat my software development more like I do with physical hobbies and start to learn to use advanced-yet-powerful tools that are well-made. VSCode is perfectly fine, but I see it as something that won't last long in one form, constantly changing things for the flavor of the year tech.

I second the suggestion to start off with org mode. You get a low stakes note taking utility to use while getting comfortable with emacs. From there spread out to learn other features at your own pace.

I moved from VSCode to Emacs with the help of Doom Emacs. You can check it out online. It’s a distribution and configuration management solution.

Generally people like to recommend writing your config from scratch but that didn’t work for me.

It comes with pretty much all you requested out of the box.

One thing I liked more than with the default Emacs setup is that I could “activate” support for a Language just by un-commenting a line in the well organized config.

Ooh, thanks! That sounds like something that will help me. I tend to do better when I can get something running like someone else has done in the past, then slowly tweak things as I learn more about it. My current VSCode setup and all my dotfiles have been slowly cribbed and edited from various sources who knew more than me about those things.

Seconded, Doom Emacs is such a huge QoL improvement over the DYI solution with a basic Emacs.

(I did use the upstream vanilla Emacs, but the pain of LSP support, etc. etc. was just too much until I tried Doom Emacs... and suddenly Emacs is usable again!)

I used doom and spacemacs for many years before writing my own config from scratch.

Not exactly what you’re asking for, but check some articles and videos about org-mode. There’s a chance you’ll get hooked on it and the following learning will be much easier because damn, it’s worth all the pain. Well, at least that was my case.