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.

  • cljnewbie2019@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    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.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year 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.