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.
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.
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.
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.
> 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!
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"
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.
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.
(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!)
You may balk at the $50 pricing, but it gives the most complete picture of how Emacs works than anything else.
I totally agree though that VS Code has a way better out or the box remote coding experience.
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.
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? (Also, how to have my cake and eat it, too.) I am sure the Emacs community has built everything under the sun, but is it as easy to setup and easy to find as VSCode?
I really want to know how I can transition from using VSCode to Emacs, because I'm starting to realize that VSCode is always going to be a "product" of a BigCo and will continue to add anti-features, tracking, and other stuff that I don't want. I'm also starting to realize that I want to be a bit more strict about my open source software usage, and try to support communities rather than coprorations.