Clojurians Log v2

My experience seems very different: Install Spacemacs and get on with commercially paid work 🤣 I did contribute back some missing key bindings and a few functions to Spacemacs and Cider, to optimise my Clojure workflow. I also wrote a book to help me learn Emacs and help me retain that knowledge. I dont think I have ever changed packages for a decade. I've added a but actually removed more packages as I didn't actively use them. The last big package change was incorporating Clojure LSP with LSP-mode. I dabbled with native compilation, but that made Emacs slower (Emacs wouldn't keep up with my typing speed, magit slow to open, etc.) I did try Doom Emacs which had different packages but I didn't notice any useful differences in my workflow, so stayed with Spacemacs. I appreciate that Emacs has a very rich ecosystem of packages and can be highly customised, but the vast majority of the time I simply want to get work done and the tools I have already are very effective.

I tend to shrink down and simplify my config over time nowadays. Every emacs release integrates more useful features that can replace bespoke solutions/packages. A lot of builtins are underrated imho

@jr0cket native comp making things slower : it’s likely the first time it compiles the packages as you’re using them, there’s no way a natively compiled package is slower. You can force compilation ahead of time also (I don’t remember the command on the top of my head but it exists)

@mpenet My experience was it did slow down loading of Magic status buffer and typing (in any mode) had a visible delay. Unfortunately native comp packages made every day use of Emacs unbearable to me. That was a couple of years ago so perhaps cause of the slow-down has gone. Never felt the need to try native comp since then.

I usually relaps when I discover a new config of somebody that is super cool and I want to write it all by hand and combine it with mine for the ultimate super mega cool config. Latest one I have my eyes on, but I need 1-2 weekends to get through it https://protesilaos.com/emacs/dotemacs

some day i'll probably declare bankruptcy with my Doom setup and rebuild ground-up, I've been Evil for years and wanna to try Meow keybindings

I've had that in the early days of my Emacs usage, these days I just paste the default configuration into my and file a task to read about it later, I only learned to add commands to Embark last week.. I find it more useful to get the 60-80% of a package today with minimal effort then get the 99% when I need it.

Pretty much. I was a happy consumer of radian for a while. Its author (also author of straight) did clojure work and saved me a lot of time getting cider et. al. setup. But that eventually bit rotted as he stopped clojure development so its benefit to me was marginal. I recently switched to minimal-emacs which has been good, but it might be too minimal and now I have to weigh the pros and cons of spending the time on my own bespoke setup or looking for another kit. Lather, rinse, repeat.

i'm overdue for actually being forced to learn elisp

https://github.com/corgi-emacs/corgi I declared Doom bankruptcy with the help of corgi, merged my corgi branch of my config repo, and never looked back. The keybinding system is all I really need and it's much more lightweight than Doom's module system, so it forces you to take more ownership over your config. Strongly recommend it.

oooooo interestingg, I do think I might make a full dive with guix when the time comes

I would really recommend against scope creep for a config rework like that, because if you go down that road, now you have to get your head around • emacs lisp • Nix • Guile Scheme • and how all of them interact

oh i've been down the nix road before, regrettably, these rabbit-holes are a manifestation of a drive towards self-flagellation; it is how I learned linux originally, I began with Arch around 2017/18ish?

one of the main selling points of corgi for me is how little I manage my config these days

fully understandable (thats why I currently run doom, after all (and astronvim before that))

you missed the bulletpoint: • think it's the best behavior possible and other should use it, include in doom-emacs and make yourself a module maintainer of that option even tho yo having no time :)

i definitely hit a few moments of “great, i’ve configured myself into a trash heap” early on in my usage (ca. 2019, 2020 or so), so i try to minimize the more drastic reconfigurations i might try.. but i definitely check out what’s available in M-x customize-group RET foo when I first take on a new package 🙂

With sufficient time dealing with Elisp, I now view every package, module, or gist not as a "final product," but as a recipe. After skimming through the readme, I typically scroll through the code. These days with gptel, things get even simpler - I simply ask it to explain things to me. Almost always, I end up adding hooks and advising functions. I have found my inner peace when I accepted the paradoxical nature of Emacs - it always works, and it's perpetually broken. I don't get angry anymore when something doesn't work as expected. Learning the built-in profiler, edebug, and other tools gave me everything I need to troubleshoot issues. Often, it takes less than two minutes to fix a dormant command that I haven't used in a while but suddenly remembered I had.

I no longer obsess over maintaining "pristine" configuration files, as my setup has grown modular enough that I rarely waste time hunting for specific settings. My Emacs workflow has evolved to be purely "goal-oriented" - whenever I encounter a problem, I simply write some Elisp code. I start by experimenting in a scratch buffer, then migrate useful code into my configuration. Often these solutions are temporary, remaining in the scratch buffer until eventually being discarded. Occasionally, I'll create a new command only to discover later that I already had something addressing the same issue, and that's just fine.

this is precisely what I'm hoping to eventually get to, the real lisp-machine experience

Lots of interesting notes here – always happy to learn how people use Emacs emacs-spin

what I'm hoping to eventually get toThe path of least resistance for becoming happy Emacsian: • Get annoyed by some personal workflow of yours (e.g., copying and pasting current browser url, having to waste time browsing a ticket on JIRA, etc.) • Create a new TODO item and forget about it • At some point, encounter the issue again • Find the TODO item and start asking LLM for potential solutions • Go back to work and forget about it once again • Get annoyed when the issue comes back at you • Explore your TODO item for past notes and finally ask LLM to write a solution • Iterate over it. Get annoyed every time it doesn't work as expected • Over time you will learn enough of Elisp to use it to quickly and efficiently solve your problems The time required to become proficient is proportional to the level of raised annoyance. My advice - get fucking annoyed and embrace it.

Yeah it's similar to how successful projects, enterprises, etc may have a backlog of a thousand bugs and it's alright

That is how it used to be, but I don’t install many new packages anymore, it’s more likely that I remove some that I never really used. Once in a blue moon I get excited about Emacs again and discover interesting new packages, only to find out that I will probably never use them. What kept me from creating a “trash heap” while my Emacs config grows is building a literate config as an .org file and declaring packages with use-package rather than installing them directly (this is probably what many people here do, but maybe not everyone who wants to go vanilla or migrate from Doom Emacs (like I did) knows about it). When I add a new package, I make a heading for it and everything related to that package gets bundled up under that heading. It is so easy to just comment out the heading when I need to debug my config or decide to remove the package temporarily. I also keep a TODO list of all kinds bugs or things that I find annoying in Emacs, so that I can keep focussing on my work and fix the bug later (maybe kind-of what ag suggested).

Yup, it's not a question anymore "oh, I could do this cool stuff in Emacs?", it's not even "can I do this in Emacs at all?", because of course you can. For me, it's mostly: "I need to find a better way of doing this shit". Sometimes there already is a package for "the shit"; often I have to get to bake some stuff. Most recent example: I only now realized that I get slightly annoyed whenever I want to resize my window using the mouse. Well, I don't touch mouse very often, I even have the keys bound to commands to do that, but for things like that I find mouse to be faster - it doesn't have to be deterministic and presize, etc. So, normally, I would grab the window divider and drag it. My problem is - my dividers are super thin, I spend more time trying to position the cursor. Then I thought: "darn, why can't I do it like I do it with my WM - hold a key and just drag the mouse - regardless where the cursor is on the window" I have a half-baked function sitting in my scratch buffer. Once it's polished I may even share it publicly. Who knows, maybe I rarely use it and it will sit there, just gathering dust.

I get some weird ideas, like just yesterday, I was thinking: "is there a quick way to find the status of my teammate? Can I send a request to Outlook and Slack and find if they are off today, etc." Or, this one that I actually use quite often: "Someone is showing me stuff through Zoom, I need this in my notes as text", yup, I do this in Emacs. The biggest value that Emacs has granted me is the ability to recognize mundane and annoying tasks and fix them for joyful workflows. Sure, maybe they can be done using bash, awk, js, python and other PLs. However, most people don't even recognize those tiny annoyances, they just accept the status quo of things.