this post was submitted on 21 Nov 2023
1 points (100.0% liked)

Emacs

310 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

  1. Posts should be emacs related
  2. Be kind please
  3. Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.

Emacs Resources

Emacs Tutorials

Useful Emacs configuration files and distributions

Quick pain-saver tip

founded 1 year ago
MODERATORS
 

I hope my question makes sense.

I am using Doom Emacs for a while now and have become fairly proficient. But I feel like whenever I am browsing emacs content online there are still many topics for me to discover. So I was wondering if there is anything that I might be "missing" yet which might help with my productivity or improve my development skills.

Sofar I what have learned, on top from my head:

  • Org/Org Agenda (refile etc.)
  • Magit
  • Vterm
  • LSP Commands
  • Multiple Cursors
  • Literal Config
  • Navigating Emacs itself (which key, debugging, reading Emacs-Lisp (abit))
  • Using Language specific commands, i.e. send buffer to repl
  • Using Undo with Vundo

Only thing I know that I still need to learn is beeing more proficient with vim keybindings, but with that I know where to start.

I know the question is quite broad, but maybe there some "killer features" worth to explore which I am not aware of yet.

I'd appreciate any input.

you are viewing a single comment's thread
view the rest of the comments
[–] ideasman_42@alien.top 1 points 11 months ago (3 children)

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

[–] Horrih@alien.top 1 points 11 months ago

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

[–] albcorp@alien.top 1 points 11 months ago (1 children)

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

[–] cljnewbie2019@alien.top 1 points 11 months ago (1 children)

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.

[–] albcorp@alien.top 1 points 11 months ago

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.

[–] albcorp@alien.top 1 points 11 months ago

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