Honestly if you want a better understanding of the software you could always try switching to vanilla and writing your own config. Also if you aren't too familiar with vim keybinds why not try Emacs keybinds, they're honestly quite good and work well. I swear by them
this post was submitted on 21 Nov 2023
1 points (100.0% liked)
Emacs
313 readers
2 users here now
A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!
Get Emacs
Rules
- Posts should be emacs related
- Be kind please
- Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.
Emacs Resources
Emacs Tutorials
- Beginner’s Guide to Emacs
- Absolute Beginner's Guide to Emacs
- How to Learn Emacs: A Hand-drawn One-pager for Beginners
Useful Emacs configuration files and distributions
Quick pain-saver tip
founded 1 year ago
MODERATORS
I just replace evil-insert-state with the normal emacs keymap; best of both worlds!
Meow.el is a great package for those who want Modal editing without having to change everything in your config to fit Evil "way of doing things"
I feel like whenever I am browsing emacs content online there are still many topics for me to discover.
This will never not be the case.
My suggestions are:
- focus on addressing known pain points
- if something seems very popular, it might be worth trying to learn why and whether it could be beneficial to you as well
- if something else sounds super-interesting, take a look
- don't fret about not keeping abreast of everything -- it's almost certainly impractical
I memorize flash cards of all the elisp functions and M-x commands.
And make them in Emacs!
let's revamp emacs early manual
You have to be trolling right lol
The thing that made everything click into place for me: buy the "Mastering Emacs" book. Read it, read it again... And again...
I still re-read it all the time and always pick up something new. I don't know to what extent using something like Doom will interfere with things, but the book is still and easy recommendation.
I don't get the concept of learning vterm, you just start it and use it with Emacs key bindings. Just stop using garbage like Doom Emacs and evil, and start making your own set up.
What even is vterm? I've never heard of this tool before.
And I agree, if your gonna use Emacs regularly your most likely gonna want to start customising it to your liking. Though configs like Doom and Space are decent for beginners, eventually they are just gonna get in the way of progress.
I think they're also harmful, OP is feeling he has to learn vim bindings due to Doom Emacs. I agree they are good for users who are heavily wounded people by vim's modal editing and shortcuts, but they need a real treatment eventually.
-
emacs-pinky impacts some users such as this https://www.reddit.com/r/emacs/comments/44c0ed/emacs_pinky/ . I've got Caps Lock mapped to both Control (down-holding) and Escape (up/down). Maybe not you at this point in your life at current usage level. And you could just be lucky and never have physical issues at all with hands and fingers and wrist.
-
vi can be found on almost any linux box so knowing the basic commands to work with text files when you might not have the luxury of installing is useful - ubiquity argument
-
the text-objects, somewhat more advanced to learn, in vim are not replicated by default in emacs and you will miss them in editing if you have put them in muscle memory. So things like da( or di( or ci" or ya{ and so on where d is the command and a( or c" and a{ are examples of a much larger list of objects that are easily manipulated
In any case things become a matter of preference and are subjective unless one remains a purist in the spirit of the church of emacs vs vim. The OPs biggest challenge is he appears to be trying to learn vim at the same time he is starting emacs. Many who came to Doom or Spacemacs were vim users switching to emacs.
I think calling something like Doom as garbage is unwarranted and objectively untrue. It is a huge community project that is addressing the needs of that community and has helped a lot of people (myself included). Simply Because the needs of that community are not the same as your needs does not mean it is garbage. Even for people not using Doom, it is a hugely valuable resource for different ways to configure packages. I no longer use Doom, but I and others frequently return to their source to learn some tips on how to configure different packages.
People should simply use the right tool for the job. If someone wants to hit the ground running with sane modern defaults, doesn't want to spend a lot of time configuring Emacs, and wants to use Vim bindings, Doom is an excellent choice. If someone wants to learn how to configure Emacs on a deeper level, spinning your own config is maybe the way to go. Neither is right or wrong, they are simply serving two different purposes, and that is fantastic!
Elisp manual. Helpful. Completions for variables, functions. Apropos.
I'm starting work on a video series called for Speedrunning Emacs in the "I want to hack everything in Elisp" sense. Emacs is a programmable interface to a computer, so my interpretation is that using Emacs and using Elisp are inseparable.
https://www.youtube.com/watch?v=QU30EZiHNQw
It's super new, so I'm recording right now and mainly covering things incidental to setting up casting for now and going over packages I've already published. Excited to get dug out of that hole and cover some of the things I want to.
Looks good. You have a good voice and speaking skills.
One recommendation is to cut the music out since people may prefer to listen to their own music in the background when watching videos or just not have any music at all.
How can I become a more "proficient" Emacs user?
Just use it. It is that simple.
I also suggest being patient and looking up the documentation and the built-in help whenever you have a problem.
Don't fall into some of the common pitfalls I see people here do often:
Don't insist on super customized Emacs according to your liking from the early beginning. Be patient, and do stuff Emacs way, or live with some more irritated moments, and leave minutiae customization for later, when you are more familiar with Emacs. Emas is to be customized by each and every one and bent to your needs and personality, but it may take some deeper knowledge of Emacs in some areas, so to save yourself some frustration and lots of time, proceed gently at customizing Emacs in the beginning. This will probably be a somewhat controversial tip for some people, but what I mean is, prefer to do the work you have to be done, over how you do it in Emacs. In the beginning, bend yourself around Emacs, and keep in mind, that the more you are used to Emacs, it will be easier and faster to bend Emacs around you.
Yes, there are many tips and stuff accumulated on the Internet, but you can not learn everything at once. With the amount of information available, it is probably better to concentrate on using Emacs to do your work, and focus on exploring only those topics that give you the most in terms of how you perform your work; for example to solve some very irritating thing or to automate something, etc. You don't have to start using Emacs for everything immediately, let it come with the time as you are getting more and more used to Emacs. What might be a killer feature for someone, might not be a killer feature for yourself.
Being popular does not always mean very good. Popularity goes in waves. You can spend all your time just re-learning "popular" frameworks and things. Instead of focusing on which package you should use for this or that; choose one and just use it. Once you find some true shortcoming that irritates you, than look for another package or for tips on how to change it, etc. If you are using Doom, I am quite sure they have already included something that is good for most people. I personally just use whatever is default in Emacs and have had no issues with it; for like 25 years now, or something there and counting.
I think this is really great advice.
Try to identify the biggest inefficiencies/annoyances that you encounter in your real daily work, and use those things as motivation for learning about a specific part of Emacs. Every time you fix some small problem with your workflow, you will become a little more knowledgeable and efficient, and over time you will become a master.
As a simple example, a beginner Emacs user might notice that they're spending a lot of time navigating to the same files/directories over and over with M-x find-file. And that might motivate them to learn about packages for opening recently visited files (e.g. recentf), or to learn about Emacs' bookmark system. That's a really basic example, but I think that repeating that general "improvement loop" over and over is how people become good at Emacs.
I want to note here that there is a eternal temptation towards "yak shaving" with Emacs, where you spend all your time working on your configuration instead of getting your actual work done, whether that be school assignments or tasks for your employer. Personally, I have a rather extreme rule that I don't make any adjustments to my Emacs config during working hours, unless I can make the change in less than 5 minutes. Instead, I keep a TODO list of possible improvements and do those on my own time.
Finally, I second the advice given elsewhere in this thread, about starting with a vanilla Emacs config. Emacs distros like Doom/Spacemacs/Prelude are great for showing you what's possible, but you will understand your config so much better if you build it up from scratch. That will also help with gradually learning how to program in Elisp, which is a total game changer and probably the single most valuable thing you can learn.
While minimal/vanilla Emacs configs aren't as flashy Doom/Spacemacs/Prelude, they can be really effective. For example, Twitch coder @tsoding uses a very vanilla Emacs config, but he does things at a dizzying speed. For example, see the following video where he is doing some coding experiments with the "tree sitter" library: https://youtu.be/-8p-Jd9n-_I?t=549
I think this is really great advice.
Try to identify the biggest inefficiencies/annoyances that you encounter in your real daily work, and use those things as motivation for learning about a specific part of Emacs. Every time you fix some small problem with your workflow, you will become a little more knowledgeable and efficient, and over time you will become a master.
As a simple example, a beginner Emacs user might notice that they're spending a lot of time navigating to the same files/directories over and over with M-x find-file. And that might motivate them to learn about packages for opening recently visited files (e.g. recentf), or to learn about Emacs' bookmark system. That's a really basic example, but I think that repeating that general "improvement loop" over and over is how people become good at Emacs.
I want to note here that there is a eternal temptation towards "yak shaving" with Emacs, where you spend all your time working on your configuration instead of getting your actual work done, whether that be school assignments or tasks for your employer. Personally, I have a rather extreme rule that I don't make any adjustments to my Emacs config during working hours, unless I can make the change in less than 5 minutes. Instead, I keep a TODO list of possible improvements and do those on my own time.
Finally, I second the advice given elsewhere in this thread, about starting with a vanilla Emacs config. Emacs distros like Doom/Spacemacs/Prelude are great for showing you what's possible, but you will understand your config so much better if you build it up from scratch. That will also help with gradually learning how to program in Elisp, which is a total game changer and probably the single most valuable thing you can learn.
While minimal/vanilla Emacs configs aren't as flashy Doom/Spacemacs/Prelude, they can be really effective. For example, Twitch coder @tsoding uses a very vanilla Emacs config, but he does things at a dizzying speed. For example, see the following video where he is doing some coding experiments with the "tree sitter" library: https://youtu.be/-8p-Jd9n-_I?t=549
Things I'd recommend checking out:
- start using dired as a file manager.
- get comfortable with macros.
- hyperbole as a bookmark manager on steroids (specifically explicit buttons).
- find a templating system for standard document/code generation (I use yasnippet after failing to make sense of srecode).
- write an interactive emacs lisp function to solve a text editing problem; extra credit for clever use of temporary buffers.
combine these😎 use multiple cursors in an editable ripgrep result buffer. or in an editable dired buffer. use project.el or projectile, use radio buttons in org or define your own buttons in hyperbole.
Window manager Exwm maybe?
I'd suggest not to attempt to become proficient at Emacs for the sake of it, instead.
- Use Emacs for whatever you need an editor for.
- Ensure your workflow is good.
- If you see some room for improvement, investigate packages/configuration.
- If you need to scratch an itch, write your own commands/packages.
Once in a while you might like to play & explore areas you didn't dig into before but you don't have to. Have a nice workflow, get your work done - and leave it at that :)
For some context, packages I've developed: https://codeberg.org/ideasman42
This is the way, adress pain points, don't do things for the sake of it.
You will naturally dig deeper in the things that matter to you
If you hear of some fancy new package, read/watch an introduction about it and ask yourself if it would actually solve one of your issues. If it doesn't really, pass
I completely agree with this summary. Find something in your existing workflow that could do with improvement, and seek out a solution. For example: you want to jump quickly between windows, look up Ace Window; or, you want to jump quickly across the text visible on the screen, look up Avy; or, you want to jump quickly between files and text in your repository, look up Counsel.
Invest in a few well made frameworks, but only one at a time, and allow yourself to internalize their concepts and key bindings. It is helpful to write out the keybindings that you intend to memorize. A framework or package will often have dozens, but you will probably only ever commit to a handful. Review the list after a month or two, and you will likely find the ones that stick with you.
I have used Emacs exclusively since the early nineties, so I've seen whole frameworks come and go. I've also wasted a lot of time on some of them, e.g., Org Mode is something I swore off almost a decade ago. What I appreciate most about Emacs is that learning it has truly been an investment, since it has had incredible staying power and there's enough in the vanilla install that I can install the package on a new Linux box and immediately be productively editing files
e.g., Org Mode is something I swore off almost a decade ago.
I'm curious (not arguing) why you swore off Org-Mode? This is why I came to emacs from more of a vim background and keeping notes in markdown.
I found Org-Mode impossibly big. It offers so many different concepts and has so many mechanisms for configuration and extension that I spent years and hundreds of yak-shaving hours configuring it, but I found it completely unreliable.
There are some highlights. The date editor is incredible and impossible to fully replace. The list editing functions and bindings are also incredible, but easier to replace and less truly useful since they encourage a sort of endless mucking with the structure of lists.
The tree structure for notes sounds brilliant, but in practice does not scale well. I thrashed around for several years between trees of different sizes: a single tree, a tree per focus area, a tree per project. Each approach brought unsolvable pain points at large scale in the details of searching, archiving, tagging, viewing, and reporting. I spent a long time thinking it was something additional that I needed to do or configure, and would burn hours getting it just right, but each solution would either get bit rot or be too reliant on the particular tree structure, so be lost when I reorganised.
I gave up and retreated to a 3 level directory structure of active/archived, area of focus, project. I instituted a naming convention for project folders. I let projects be small. I found ways to query the directories using counsel-git and counsel-ag, namely search over filenames and the silver searcher or find and grep.
I completely agree with this summary. Find something in your existing workflow that could do with improvement, and seek out a solution. For example: you want to jump quickly between windows, look up Ace Window; or, you want to jump quickly across the text visible on the screen, look up Avy; or, you want to jump quickly between files and text in your repository, look up Counsel.
Invest in a few well made frameworks, but only one at a time, and allow yourself to internalize their concepts and key bindings. It is helpful to write out the keybindings that you intend to memorize. A framework or package will often have dozens, but you will probably only ever commit to a handful. Review the list after a month or two, and you will likely find the ones that stick with you.
I have used Emacs exclusively since the early nineties, so I've seen whole frameworks come and go. I've also wasted a lot of time on some of them, e.g., Org Mode is something I swore off almost a decade ago. What I appreciate most about Emacs is that learning it has truly been an investment, since it has had incredible staying power and there's enough in the vanilla install that I can install the package on a new Linux box and immediately be productively editing files
Learn lisp :)
Just Use Vim
The killer feature is emacs lisp. Once you've gotten a handle on the general, day to day use of emacs and the packages in your quiver the next step is to learn the language that powers the system. This will open up an incredible amount of power and customizability. It will change what you think emacs is, fundamentally.
Writing your own functions, modes, and packages is the thing that makes emacs emacs. Right now, you configure your system. But once you learn emacs lisp you will be able to customize it. This is a huge difference.
I recently made the switch from Doom Emacs to Vanilla Emacs because I wanted to get a better understanding of the nuts and bolts of emacs-configuration which meant getting more into elisp and becoming more familiar with how to customize things from scratch in that language.
Doom was great but I also found it abstracted away some of the help I found online which was directed mostly at vanilla emacs users with use-package and such. I was in no way qualified, to try to understand how doom built up from vanilla emacs to provide, for example, its package management abstractions.
I chose Doom initially as I was a long time vim user who know h, j, k, l and other movement commands on muscle memory. If you aren't already familiar with vim keybindings you can try a game like this https://vim-adventures.com/. I do prefer vim keys to emac defaults since holding down modifier keys to do commands have caused issues with my hands. I also use an emacs package called god-mode and evil-god-state (evil = vim capability in emacs) to reduce having to hold down modifier keys for commands.
The took the move from Doom to Vanilla emacs slowly and I set things up so I could run both my Doom and Vanilla at the same time. I didn't want to lose productivity until I could get my Vanilla emacs config up to speed. I don't know what OS you use but I simply asked ChatGPT about running two different configs at the same time for my OS and it walked me through. You will maintain your ~/.doom.d directory for that config and then you can start another directory like ~/.config/emacs with an init.el file for that. I've found ChatGPT very helpful for emacs in general though it does get a lot wrong too but not enough not to use it.
I'm going through the System Crafters "Emacs from Scratch" playlist slowly. You can find that playlist here https://www.youtube.com/@SystemCrafters/playlists . There is a playlist on "Learning Emacs Lisp" too but I haven't made it to that one yet.
Finally I recommend literate programming setup for your config. The "Emacs from Scratch" playlist from video 7 shows that. Thus my init.el is generated from an init.org via org-babel-tangle. The advantage of putting your config in org source blocks like this is you can create a hierarchy within org and put in all the extra notes and links you want to explain the why and how of your configuration without cluttering up the actual init.el with a bunch of comments. It's easier to read and navigate, at least for someone with little elisp experience like myself. This is a fairly popular example of emacs configuration via literate programming https://pages.sachachua.com/.emacs.d/Sacha.html.
I also recommend putting your config files under git version control so you can easily get back to configs that "worked" as it can be easy to make breaking changes and you will want to revert to an older copy.
Use "C-h k" and then press keys to find out what Doom emacs is using. You will begin to see packages like consult, counsel as part of things you will want to install in a Vanilla package as the worst thing about Vanilla that Doom will spoil you on is autocompletion lists.
rome wasn’t built in a day and neither will be your knowledge of emacs, just use it, repair stuff as you need to, change stuff when you need to, just that
There's so many things you can learn from! Since you mention wanting to improve how you use Emacs for development, a couple of features that I use everyday and feel very "emacs-y:"
- compilation-mode (`M-x compile`) - It defaults to a `make` but the resulting buffer is useful for any sort of build/compile/test job that you want to spawn. For example, I'll use Projectile's `projectile-test-project` command (`C-c p P`) to quickly run jest tests for my TS projects:
https://i.redd.it/xyte0s83if3c1.gif
- occur - (`M-x occur`) I use this mostly as a persistent search buffer. Basically, you can list lines that match a search string and then follow and/or visit them in the corresponding buffer. I like that the numbers in the occur buffer give you a rough idea of where the search term is in the original buffer. Pressing `n`/`p` in the occur buffer advances to the next line as well as gives a quick highlight in the original buffer.