How do I get from the tutorial to being productive?

[deleted]

Very good question. Took me ages to form an emacs habit, and i was consciously trying to. My honest answer is find a barebones way to use emacs as-is now, and by trial and error you'll figure out more as you go. ...also, get some lisp practice in, you'll need it

You don’t. You get productive by learning to write code debug it and you’ll get that with any editor. Don’t focus on finding the perfect editor that’ll make you productive: focus on the work. And as you work, when you find yourself doing the same things again and again… write a macro or some elisp for it. Explore packages but don’t be a slave to them. Write code. You can learn to use any editor well, but Emacs (and maybe vi) are the only editors that'll stay with you your entire career. Learn the tool to do the job. Don’t buy the perfect tool in the expectation that if you just configure it right it’ll magically make you better. And good ol’ `C-h f` will get you the rest of the way ;-)

[deleted]

For me, it's a never ending process that I tune and adjust, analogous to a carpenter's workshop. I would recommend starting with identifying the key-bindings that you find unsatisfactory, ask yourself where they should go instead. Try it out. Screw it up and try again. Maybe decide the original was best. Next would be, rather than writing too much elisp, think about some keyboard macros that you want to have. My favorite, for example, I almost always have bound to F12, is to take the text between start-of-line and point, wrap it in parens, execute it, then delete the text. It's an easy keyboard macro that does stuff only I like and others find strange. This, to me, is the essence (with all its pros & cons) of emacs.

Others have given some pretty good advice. Here are some of my own thoughts: * Learn to make notes of your settings and any corrective actions/settings you have to make in Emacs. Check Org-mode. * Learn how to use Org-mode and make use of it e.g. to maintain your Emacs configuration files. * Don't try to learn too many new things at once and too quickly. This will not work at all! * Using Emacs is an ongoing learning process. Don't be afraid to experiment and learn new things. * Remember to backup your data. * Keep a list of all the sites/sources with advice that have helped you with something.

Try Doom Emacs or Spacemacs. You'll get most of the functionality without any of the tedium. There's a series on YouTube called Doom Casts that have nice tutorials to get you started, and Doom Emacs also includes some extra documentation on most of its 'modules' (pre-configured packages). Default Emacs is awful at providing toeholds for getting started. It's similar having instructions to build a house without knowing what you want to have in it. It's better to start with a small house and make changes when you realize 'I could use a shed' or 'solar panels would be nice'. You'll learn more from addressing any points of resistance as they come, as opposed to solving all your problems at once. Doom Emacs is the way to go if you wanna dive in deep. Spacemacs is great with you just want to get started with knowing the general offerings right away.

I'm not an emacs user anymore BUT when I used it I was obsessed with it's idea of such a highly customizable editor which I technically can turn into any IDE for anything I've went on trying neovim and emacs, trying to configure them how I like, b ut in the end I've noticed I've spent way too much time configuring them and I don't have a good configuration I like still Eventually I returned back to vscode for general programming and jetbrains' IDEs for specific technologies. The customization of emacs and neovim was cool but really there are just some small things in vscode and ides which you can do via gui with your mouse which are just more convenient and as such make me more productive, I really didn't feel an increase in productivity using emacs

> I'd really like to have things like go-to-definition/go-to-references tags + grep is the traditional way to achieve this. Emacs can interface with tags (generated by various programs) and the search output of grep (and its various clones). Personally I use universal ctags. And ripgrep with the **rg** package. Regex based tooling is not perfect but can be effective. When a fancy new language like Rust pops up you hit the ground running on day 1 with your same old workflow, same old tools. > git management I use a combo of command line git, tig (ncurses UI), Emacs vc, and magit. I haven't found any single git client that is best in every aspect. > I see use-package docs saying it's not a package manager. What are they talking about? use-package provides syntax sugar only. > What is the package manager then? The code in package.el. The package repositories are elpa, melpa, etc.

First, *don't* turn off the menus. I know some people like to recommend that, but I think it's a terrible idea, *especially* when you're getting started. I still leave them on, and I've been using Emacs since the nineties! Browsing the menus is a great way to find out more about (or remind yourself of) Emacs's capabilities. In particular, the mode-specific menus! As a bonus, `C-h k` or `F1 k` (help on a key) works with menu items as well as key-presses! Also, in general, don't be afraid to use the mouse if it feels comfortable. You'll probably become more keyboard-oriented as you gain experience, but don't try to force it! Take advantage of Emacs itself to help you learn! For example, check out org-mode! When org-mode was introduced to Emacs, I skimmed the docs and was extremely intimidated, but then I had the idea of trying to use org-mode itself to help me learn org-mode! This worked *brilliantly!* I started with a simple list of questions ("\* WTF is *X* and why should I care?"), and gradually reshaped it, adding and expanding as I learned. The only real danger here is that once you get familiar with org-mode, you may never be able to go back to other editors! :)

[deleted]

Use some emacs distribution (spacemacs, steve purcell's emacs.d, doomemacs, prelude, Centaur Emacs, my emacs.d ...). Every week spend at least 1.5 hours to read distribution's code. One year is enough to master emacs.

I picked up Emacs 2 years ago. I had long used other text editors. I went down the path of installing Doom and then Spacemacs. Neither one felt quite right. So I cleared out my `init.el` and started the tutorial. I went through it twice. Then I started using the Emacs as is. And paid attention to what I wanted to do. I knew that I liked filter lines by search; and went looking for that feature. I found Ivy/Swiper/Counsel. So I explored and added that to my init. And went back to work. I wanted to jump to a file with a "fuzzy" search, much like TextMate and Sublime before hand. Projectile had some of that feature. So I explore that and it's other features. Again, I looked at what are the tasks that I'm doing, and is there a faster way? Over time I built up a rather large init file, gathering packages that I use regularly; provisionally adding packages and playing with them; always looking at what I wanted to do, didn't know I could do, and then practicing. This incremental approached helped me better "own" my Emacs. https://github.com/jeremyf/dotemacs

Just keep butting your head against the wall. No other way to get good. And what is productive anyway? Just improve a little bit every day. No need to be some super-efficient machine.

I would start by watching this presentation: [https://www.youtube.com/watch?v=eX9m3g5J-XA](https://www.youtube.com/watch?v=eX9m3g5J-XA) Then find out how to develop each of the 7 habits inside emacs. As others have posited, learning to use emacs is an act of discovery. Also, some of the emacs "distros" (spacemacs, prelude) have modules already configured to make some of these tasks more powerful. But I think there is a benefit of learning the basics before embarking in such configurations. After you develop those habits, every day, find a task you need to do repeatedly (what I call annoyance) and find a way to address it. I keep a file with annoyances, so when I have time, I try to learn how to solve them. I suspect most mortals will never master emacs 100%. However, this act of discovery makes emacs a fascinating tool to use. oh, one last suggestion. Start using org as soon as possible. Org has changed the life of many of us, emacs users. In fact, I see emacs now not a text editor, but as personal information management system.

> Is there a straight forward way for a noobie to install some basic packages like magit and some JS modes that get me up and running? Click on the "Options" menu, then click "Manage Emacs Packages". You'll be presented with a list of packages available for installation. If you are using Emacs 28.1 or newer, Magit will already be listed. (Emacs 28.1 is the first version to include the NonGnu Elpa package archive by default. You can obtain Magit from there or from Melpa.) If you're using an older version of Emacs, then I'm afraid it's not quite as straightforward. You'll have to add the NonGnu and/or Melpa package archives, as described below. ... One way you can do this is to go to the menu again. Click "Options", "Customize Emacs", "Specific Option". At the prompt, type "package-archives" then press Enter. There will be a list of package archives, which at this point will only have one listing, the "gnu" package archive. Click the last "INS" button on the page to insert a new archive definition. In the "Archive name" field, type "melpa". In the URL or directory name" field, paste the URL for the MELPA package archive: https://melpa.org/packages/ Now, click the "Apply and Save" button. Go back to the "*Packages*" buffer, and on the menu, click "Package", "Refresh Package List". Magit and many other packages should now be available for installation. ... For most packages, once they're installed you can use them without any further configuration. For example, now that you have Magit installed, you can use it by pressing M-x, typing "magit" and then pressing Enter. An easy way to configure most of Magit's options is to go back to the Customize interface. Click "Options", "Customize Emacs", "Specific Group..." Type "magit" and press Enter. You'll see a list of configuration groups that hold various Magit settings. You can edit them in the same manner as when we added the melpa archive above. ... Most of what you'll see online about configuring Emacs involves manually editing your configuration file. If that's necessary, you can usually find out what you need to add by reading the package's description which you access by clicking on the package in the "*Packages*" buffer. Alternatively, you can check the web page for the package (usually on GitHub, Gitlab, or a similar website). You can even review the package's source code which often comes with instructions at the top of the file. > I see use-package docs saying it's not a package manager. What are they talking about? What is the package manager then? Use-package is a macro to help with organizing configuration files. It can call upon a package manager to ensure that a package is installed, but it doesn't actually handle that itself. The built-in package manager is package.el. There are also external package managers you can install. At this point, I wouldn't worry about use-package. I would think that at this point your configuration file is very short and not in need of a special tool to keep it organized. > Are there good guides for getting there that actually explain what's going on each step of the way? If you really want to know what's going on, do "C-h i m eintr" to read the Introduction to Programming in Emacs Lisp". Also, check out [Mastering Emacs](https://www.masteringemacs.org/) for some great articles on Emacs usage. The website's maintainer (and author of the book), is a regular here.

[deleted]

[deleted]

This is not a direct answer to what you asked, but I think once a person is done with the tutorial, the natural follow up to it is the excellent [An Introduction to Programming in Emacs Lisp](https://www.gnu.org/software/emacs/manual/eintr.html) from the late Robert Chassell. It will help you learn not only elisp but a lot of fundamental things about how emacs works. It's actually better to read it from within the emacs documentation (\`C-h i\`), because you get to run the commands right there.

Learning Emacs is kind of like speaking a foreign language. You can read tutorials and blog posts and such, but real mastery of the thing requires you to go out and use it for things. It will be a bit of a struggle at first. What I recommend is keeping a notes file (or even a physical notepad) in which you can record the pain points you encounter during your daily work. Then you can, once you’re done with said daily work, Google around and figure out how to fix those pain points. Which you almost always can, because Emacs is hackable and customizable to a degree achieved by no other editor. `use-package` is indeed not a package manager: the package manager in Emacs comes built-in, called `package.el`. It even has a user interface (try `M-x package-list-packages`). use-package is instead a very pleasing syntax for requiring the presence of a package, from within your Emacs configuration file, and customizing that package’s behavior appropriately. use-package can download packages from many different servers. Don’t worry too much about the differences between MELPA and GNU ELPA and NonGNU ELPA and whatnot. I use MELPA and recommend it highly. To get a sense of the package ecosystem, I would start by checking out [MELPA’s most popular packages](https://melpa.org/#/?sort=downloads&asc=false). (Be sure to check out its [getting started](https://melpa.org/#/getting-started) guide before you try to install anything. As far your specific questions: - SP modes: the two most popular packages are `lsp-mode` and `eglot`. lsp-mode is fairly fancy and heavyweight, comparable to the experience you might get out of other IDEs. eglot is less featureful but integrates more natively with Emacs’s built-in functionality (like xref for jumping between definitions). My use case makes eglot better for me. You should try both and see what you like. - git: Magit is the most popular git integration, and it’s also one of the best pieces of software I’ve ever used. Love it to death. - syntax highlighting: language modes tend to come with their own syntax highlighting, but `emacs-tree-sitter` is gaining popularity, as it is more performant than Emacs’s built-in highlighting functionality. - JS: Emacs comes with a JS mode built in, but you may want to check out `js2-mode`. A helpful thing to do is to check out people’s literate Emacs configurations. I would humbly offer [mine](https://blog.sumtypeofway.com/posts/emacs-config.html) as a fairly well-commented example. I don’t have a massive amount of custom Emacs Lisp, nowhere close to someone like [Prot](https://gitlab.com/protesilaos/dotfiles/-/blob/master/emacs/.emacs.d/prot-emacs.org), but I think I do a fairly decent job of telling why I do things.

Much like any other tool in life, if you don’t get a *significant* benefit that overrides the cost of unlearning, relearning, setting up and maintaining the alternative, you might as well stick with what you have, especially if it’s an industry standard. If all your coworkers use VSCode and install a new workflow with a couple of mouse clicks while you are stuck writing lisp functions, you aren’t only unproductive, you’re uncompetitive as well. Think beyond just toolchains, what if your company starts some kind of pair programming / live review? integrates ci/cd extensions? That said, beyond minimalism, there are rewards to emacs and vim in the form of modal editing and org-mode. So if you feel setting them up daunting, start with bringing modality into your existing workflow or using a distribution like doom emacs to give you a good starting point. You should consider a total switch only if your existing solution is unworkable. Productivity is purely subjective and the most minimal and customizable solution is not always the answer. My personal solution is doom emacs for productivity with org mode, text authoring with latex / pandoc and random text editing and VSCode with [VSpaceCode](https://vspacecode.github.io) for coding.

Practice

Try the Hyperbole package along with Org mode. It exposes a lot more of Emacs capabilities and makes point and click navigation much easier without the need for many other packages, e.g. goto definition and completions work with tags files without the need to run LSP servers in many cases. All your text is automatically hyperlinked with minimal effort in your part.

Check out the https://www.youtube.com/c/SystemCrafters While it will still take a few hours to gain substantial knowledge from them, I found those the most effective. Protesilaos Stavrou aka Prot, also has great videos, which not just showcase but explain specific Emacs packages. Maybe start with this one, about the different ways to consult Emacs itself for help: https://www.youtube.com/watch?v=46w9e4GAjsU There is also a curated list of Emacs resources, including tutorials: https://github.com/emacs-tw/awesome-emacs#tutorials I found that watching Mike Zamansky work with Emacs kept me going on the Emacs journey. I'd caution against using evil, because that's an additional layer, which complicates the learning process. You will find yourself wondering often, whether something is not working because of evil or evil-collections or what approach should you take for accomplishing a certain task, the vi approach or the emacs approach. So, unless you are already fluent in vim and find it an impediment to switch back to non-modal editing style, maybe delay the introduction of evil mode.

Before everything else, indeed, just practice what you already know, so the new ways of doing things won't feel like a chore. You will realize eventually, that the Emacs approach is not more complicated, just different. Or maybe it's more complicated, but in exchange a lot of otherwise even more complicated operations become less complicated.

Use Emacs daily. Yes, all that nonproductive faffing around is going to suck, but it's how you master using the tool. Every time you find yourself at a friction point, look stuff up here, on the Emacs Wiki, or ask somebody, and then practice with the workflow a bit. The skill ceiling with Emacs is absurdly high. There are things you can do with it that you didn't know you *could* do, but getting there is just going to take time and practice. So put the time in and remember to have fun.

See I come at it from the opposite angle. I keep trying Visual Studio Code because everybody loves it and everybody *says* they're so much more productive with it. But it really isn't much better than Emacs at anything significant and it's a lot worse than Emacs at things I value very much (like adding real, useful functionality into a running editor session as I use the editor). So I grumble and slouch back towards Emacs, wondering to myself why "modern" tools are so limited and stuck in the past. Stick with it. It'll suck at first because it's not what you're used to but you'll cross a threshold where you'll wonder how would you ever get along with Emacs's tremendous power. And if you use Visual Studio Code at your job and only use Emacs at night when you want to feel like a superhax0r, that's fine. Pick a project and try to complete it with the tools that Emacs gives you (including the ability to make your own tools, often with a page or less of Emacs Lisp!).

side trick: watch videos of people using it - emacsrocks - emacsconf - others I've read emacs manual maybe twice ~fully, I've read blogs, ... books... no matter how much I tried, people always came up with ways to use emacs highly productively that I never foreseen have fun ps: this also applies to other tools, vi, good old unix shell (juggling with find/grep/sed/awk quickly is a good intro to high speed)

Learning Emacs is a life long journey. If you graph productivity over time, it goes down at first, then eventually picks up and rises above other editors, and continues upward forever. The best tools for learning are the help facilities inside Emacs itself. All the C-h keys, and the actual source code. Also EmacsWiki, this subreddit, the mailing lists, the irc channel. For many common programming tasks, rather than trying to emulate the exact workflow you used in some other editor, it’s often better to take a step back and learn the Emacs way to accomplish an analogous task. A lot of concepts in Emacs evolved in parallel or even before the analogous concepts in other more specialized editors of today. Bottom line is it takes time, but should pay off in long run. In my work I started by using Emacs in parallel with my previous editor so I could still be productive. Over a period of several years I gradually migrated bits of my workflow from old editor to Emacs.

I'm a C and JavaScript guy (and Lisp). But that doesn't really matter when it comes to Emacs. What I did when I first started using Emacs, was using whatever development environment was mandatory at work for the project we were working on, and using Emacs whenever I had the chance. At first, it was only for simple file editing, like writing some piece of code that would take me 5 seconds normally but 10 minutes with Emacs. Sometimes I wanted to save the file and accidentally closed Emacs or introduced some garbage text, etc. The actual build, jumping to definition, debugging and all that stuff, I still did with the other text editor. Find the not so important or so urgent tasks at work or in your daily activities and use Emacs for them. Slowly, but surely, I've started reading more about Emacs, doing more work with it until I was able to switch to it full-time. That takes time. Have patience. Discover small things daily/weekly/monthly, depending on your pace. Have the confidence that you'll get there. Try small examples, play with it, play with lisp, play with the configuration, change stuff in a running Emacs instance and see how that affects your environment; you like it? keep it; you don't like it? nothing bad happened, just revert to the previous configuration or just restart the whole thing; explore and don't expect to find a ready-made solution just for you out there, since that is the beauty of it, after all: you can make your own solution. Take is slowly and have fun.

hey just a reminder: if you are looking for 1to1 support for learning Emacs you can ping me to get in touch with some of the buddies https://github.com/ag91/emacs-buddy

Well, hello there :) I'm not your coworker, but I used professionally both emacs and vim. Right now I use Nvim

If you have gone through all the tutorial, you're already halfway there: congrats!🎉🎊 I'd say, think of what you want to do with your editor (and in your question you provided a pretty good starting point). Then, search on Google for the single features/packages, and integrate them one at the time. The comments at this post are pretty good suggestions. Take one, read its GH README, then `package-install` it and add the configuration in you init file. Take your time to play with it, and repeat. Hope you have fun with Emacs, welcome aboard! 😃

The point is, the question you're asking - you will not be productive for a long time. You've switched workflows. It's like changing the way a river flows. Probably, the better you were at VS Code, the longer it will take. Ideally, you'll be more productive in the end, but that may not be the case.

I suppose it’s not just what you do but how you do it that matters to some.

> It’s just so frustrating when I’m thinking, “this is so easy in VS Code!” I don't disagree; my experience adopting Emacs had some initial frustrations. But by the time I chose to adopt Emacs, I'd been using other coding text editors for about 15+ years. I had ideas of what I wanted. What fundamentally sold me on Emacs was the `helpful.el` package. It opened the hood and easily showed me all the interacting parts of Emacs. Having that degree of introspection told me "I was on the right path picking Emacs." And I accepted the "slow down;" instead of comparing features, I went about my tasks and would pause when I got to the "and now how might I do this?" Then I'd go and learn. All of this was great. And then I started using Org Roam and Org Mode. I had long missed having a note taking tool that integrated with my text editor; after all note taking is similar to coding: you type lots of things and want quick connective functions. Now, when I learn how to do something "better" in my note taking tool, that immediately transfers to my coding tool, and were I to use Emacs for email, it would transfer there as well. So, if you can flip your "this is easy in VS Code" to "What might I learn in VS Code? And Emacs?" suddenly Emacs becomes a very attractive course of knowledge acquisition. It does require time. And perhaps you can keep using VS Code "during your day job" and practice Emacs as a hobby. It's okay to slow down today, so you can enjoy the long journey ahead.

Force yourself to use it and whenever you don't know how todo something or think there's probably a command for something look it up.

Others have mentioned a number of great resources but I'll say that you can be very productive as soon as you know the basics - just start using Emacs instead of whatever you used to use. As someone else mentioned, don't turn off the menus and when you think "hey, there should be a better way to do this" for something, poke around the menus / help system. In the mean time, over time, read stuff or watch videos, either on Emacs in general or for specific things you want. Others have posted some options like Prot, System Crafters, and the videos I've produced. I also, personally love Mastering Emacs which was also already mentioned. ​ Then, you can incrementally add features over time. Another suggestion is to build microhabits - that is, pick one feature or technique and force yourself to use it until it becomes natural. A good beginner one is moving the cursor via search. Many people use the mouse or arrow keys to move the cursor but it's frequently faster to use search. So, for someone who's only used the mouse or arrows, they can say "I will use search to move the cursor" and then stick to it. So, when they want to go down 10 lines and 15 over, instead of clicking or arrowing, they type "C-S" for incremental-search and start typing the word at the location they want to go to. Then, they realize that some have improved on that so they look up videos or articles on things like vertico or selectrum and it's off to the races. ​ The key is to just start using it and don't feel pressured to learn or set up everything all at once.

i had the same experience. constantly comparing Emacs to IntelliJ... there are soooo so so many things I like in IntelliJ, which just work out of the box, or are just a sanely-explained setting away. but I've started to hit limitations, regarding how window splitting and navigation works, especially when I run multiple Clojure REPLs. i can't utilize the resources of powerful remote machines easily either, so I always buy expensive apple hardware, with almost the fastest CPU and a lot of RAM, because IntelliJ is not exactly easy on the memory. If anything doesn't work the way I would like, i have no chance of fixing it, without learning JetBrains' huge Java Plugin API. So I'm increasingly feeling uncomfortable with this situation. I want a smaller solution, so my workstation doesn't have to be that powerful. Then I can just keep upgrading some headless, on-prem or virtual server, running Linux and/or BSD, which runs the software I develop. I want more understanding and control of my main tool, the editor/IDE, which is easier to achieve, if it's smaller. I want my workflow built out of small, composable operations, instead of bespoke features, what IDEs have. being able to do almost everything from a non-graphical interface feels like future-proofing my skills. if our civilisation crumbles, it will be extremely useful to be able to work effectively on old hardware, over limited bandwidth... that's why I keep on investing into learning Emacs.

1. What's your motivation for learning Emacs? I don't want to depend on IntelliJ, which kinda forces me buy the latest greatest Apple hardware. I can't tweak IntelliJ either, which feels more and more limiting. 2. What do you want to achieve by learning Emacs? I want more control over my computing environment, while still being very capable. I want to be able to do advanced work, even from a cheap, weak, low-power consumption, long battery-life, silent workstation either directly or over thin bandwidth, so I'm hardly constrained by where do I work from. I want to reduce my software tooling dependencies. 3. What convinced you to get started? Was there something which you missed or get annoyed by in VS Code, or was it something you saw Emacs doing? I tried Doom Emacs, which proved, that Emacs can be configured as a very capable IDE.

Sooo I was in the same position as you a few month ago! I've used VSCode + vim emulation for PHP development and transitioned into a new job where it's c++ and QT. A colleague there used emacs and 2 weeks before the job I started exploring the whole emacs thing. Since I already knew my way around vim I installed evil to get at least the basics down and have some functionality to get around emacs. After that I noticed a couple of things that I deemed "missing" and installed them too. By doing this I learned about use-package etc. and got the basics of the init.el file down. Basically during "building up" my config file and messing around with simple hello-world projects I noticed what's missing for me and what should be changed and well, I googled how to change it. By doing that you discover keybindings, keymaps, prefix keys, a bit of elisp, how use-package works and all of its features. etc. etc. etc. It takes time, but for me this worked out really well. It took me basically 3-4 weeks to become productive. >I'd really like to have things like go-to-definition/go-to-references (probably using an LSP), searching project for regexes or just words, git management, syntax highlighting, debugging, etc. If you browse /r/emacs and hackernews and whatnot you might come across many different packages that solve some parts of this. 1. Projects -> project.el or projectile (I currently still recommend projectile since it's the older more established and better working version) 2. Serach by regex -> rg.el for a more traditional interface, or use the default commands that are there. If you have vertico/consult installed I highly recommend to use consult-ripgrep 3. go-to-definition etc. -> just use lsp-mode as a starter. Works really well out of the box. If you want a more modular setup maybe checkout eglot. 4. git management -> magit. 5. syntax highlighting -> emacs does that out of the box using its major modes. 6. debugging -> lsp-mode comes with dap-mode but in general, debugging is not that great of an experience. >Are there good guides for getting there that actually explain what's going on each step of the way? I hate when it's a bunch of copy pasting. I want to understand what they are doing so I can change the parts I don't like. If you build your config like I did, step by step you can just check the documentation of each package. Emacs and it's ecosystem is really well documented. In general you can use "C-h R" to search all installed manuals. >I'm also curious about using things like use-package or just using the default stuff of emacs. In short. Use use-pacakge. An endless discussion can be had about use-package vs. straight vs. DIY package manager vs. Nix vs. basic emacs package.el but I personally think, 90% of users will be fine with use-pacakge as a starter and once you get to know use-package a bit and notice it misses a feature you want, you can still switch to another package-manager. --------------------------------- Ok to get to an end. If you wanna build your own config and customize emacs exactly to your liking I think that adding part by part is the best way to learn and get the desired result. If you are new and just wanna get started similar to VSCode etc. use an emacs-distro like DOOM or Spacemacs.

By starting. By doing. By stopping worrying about your config or "ultimate efficiency" or by "learning more". But by DOING. If you find yourself doing something **repeatedly** and doing it is painful or annoying, AT THAT TIME look into making that specific thing more efficient or learn a better way to do just that. Then get back to doing things. Do that for a few years and at the end you will have a config that is not only efficient but entirely "yours".

>Learning emacs is a bit overwhelming. Yes it is. If you really have the endurance or curiosity to do it, do this: the next time you would open a document in VSCode or vim or netbeans or whatever the current fad is, open it in emacs instead. Do your work. Notice "hey, I miss [feature X] from my old editor!". Google "how to do [feature X] in emacs". Add it to your config file. GOTO step one. Repeat the above algorithm until a) you get frustrated and bored and return to a different editor or b) you cannot imagine using any other editor because [unbelievably complicated feature XYX] would never be possible there. If b), welcome to the emacs community!

I think you're overstating the difficulty. For someone who isn't intimidated by code and configuration and who is motivated to do it, it's not that hard. As others have said, the things they want to get to (LSP interaction, projects etc) are easily achievable. Just go one step at a time.

Not everyone finds learning tedious or wants someone else to do it for them.

[deleted]

Yeah but you are spreading fud about Emacs being unusable and it is misleading at best.

I apologize, I replied from my notification bar and thought it was for a different post. I agree. Emacs from Scratch is a great example of vanilla Emacs. I still there should be more beginner's support, but perhaps I was a bit too inflammatory about Emacs's ease-of-use.