There is a lot going for #Obsidian in terms of UI performance and UX niceties, but one thing keeps pulling me back to #DoomEmacs and #OrgRoam: laser focused keyboard oriented setup out of the box

I can move subtrees around quicker than I can think.

(or I could if #Emacs didn't freeze up for 30 seconds randomly. oh well, can't have it all. any by "it all" i mean "widespread adoption of async UI patterns in your favorite editor".)

I have really been wrestling lately with my config.el file for @doomemacs

The issue seems to be that the after! macro does *not* work, and I end up with custom configurations not loading

This manifests with is my dape-configs, so when I relaunch emacs after an update (I use emacsclient) I get... no configs (until I go to config.el and C-x C-e on those blocks)

I think my hacky solution has been to just use use-package dape instead, but how is after! supposed to work?

#emacs #doomemacs

I'm considering apostatizing from the church of #emacs. the original allure was, for everything you want to do... "emacs has a package for that." that largely seems to hold up.
but.

#doomemacs manages the whole dependency graph for me, which is pretty great. Except when it fails. I made an attempt to learn #cobol for job hunting reasons, so i had to leave emacs to set that up.
projectile seems to have some weird rules by which it decides what is and is not a project.
but there's also the other old cliche; "emacs is a fine operating system; it just doesn't have a good text editor." doom emacs lets you use the spacebar instead of ctrl for everything, and on top of that includes evil mode so you use vim motions... Emacs wants to be a text editor; as evidenced by the fact that one never opens a "project", one opens text files. So if all of these other things are extra tools, why not just use vim? the text editor you're mimicking anyway?

on the other hand, all of these are skill issues. 🤷

I've been a #DoomEmacs user for some time, now, even having curated my own literate config out of their "static" files - along with all the extra stuff one adds to such a thing.

As one does, in the past I've also attempted to do my own #emacs config from scratch, usually falling into the "let's recreate doom!" hole, whether I wanted to or not (thus the reason I just went the route I did).

Over the past couple of months I've decided to - slowly - do the emacs bankruptcy declaration. Now, just to make things even more interesting I have decided against the use-package macro. Why? Because why not!

I've been using my scratch build for a month or so, haven't even opened my doom config up. It's been a great process, learning process, more understand of the process. It helps that I've been on a learn lisp quest for the past couple of years, too (#CommonLisp, #sbcl, #clojure, #elisp of course).

The large emacs distros are great an an excellent way to find curated packages. Doom is even a really nice framework. Sometimes you just want to do your own thing.

mastodon.el #authentication #fail #annoyance

#doomemacs
#emacs

Sometimes doom upgrade claims "Doom is already up-to-date!" for days when it's clearly not the case. A quick fix which works for me is:

[in ~/.config/emacs]
```
git pull origin master
```

Followed by:

```
doom sync -u
```

#emac #doomemacs

I am about to give a workshop about #reproducibility in the context of #ROOT #technology using #doomemacs #emacs (cf. https://doi.org/10.5281/zenodo.17157587).

Now I am wondering how I can make sure that the participants have installed all necessary programmes? I came up with a little test script: Please #help me to improve the script testing for edge-cases; execute the script and let me know if it works and/or what can I improve: https://gitlab.git.nrw/-/snippets/113

Thank you! #retoot #BoostoK