2 years of yak shaving

Just sharing my Emacs configuration that I've been working on for 2 years now, feel free to copy snippets to your emacs config or even open pull requests/issues for adding functionality you'd like to see in this config. html: [https://diamondbond.neocities.org/emacs.html](https://diamondbond.neocities.org/emacs.html) org-export-html-theme: [Nicolas Rougier's nano theme](https://github.com/DiamondBond/emacs/blob/master/resources/nano.css) Id appreciate any sort of feedback or questions :) Note: I use athena emacs because of [this longstanding gtk bug](https://gitlab.gnome.org/GNOME/gtk/-/issues/2315#note_795365) (tldr; gtk emacs does not survive session logout and log back in but emacs compiled with lucid & athena does.) Note2: Please refer to the [dependencies](https://github.com/DiamondBond/emacs/blob/master/docs/dependencies.org) section if you're going to attempt to run this on your machine. Note3: [system-configure-options](https://github.com/DiamondBond/emacs/blob/master/docs/emacsfromsource.org#configuring)

This is cool. Thanks for sharing. I’ve harvested some gems from your config to use in mine. Much appreciated!

I'm surprised so many people outright turn off backup file creation, which makes me think if I'm too clumsy for my own good. Backup file has saved me more than once when I accidentally deleted a portion of largeish org mode files. If you're annoyed by Emacs littering the current directory, then the solution is to use backup-directory-alist not disabling backup files! Also vc-backup is a really nice frontend for backups: easy diffing between backup file and current file, backup file creation time, etc. I would highly suggest to check it out.

Lots to steal! I do find the discord rich presence thing \*insane\* though.

Most of my workflow involves writing things that are version controlled. So backup files, while still helpful, aren’t 100% necessary. They can still prevent me from loosing work if I’ve done something in between commits though.

I enjoy a well-structured literate config. I don't have a well-thought-out or executed structure but it's nice to look at someone else's.

I think you have a go-mode hook in your Rust use-package block

Thank you so much for catching this! I haven't used rust mode yet which is why I haven't noticed this.

Just rewind a year back in my git log and you will see a complete lack of structure! Structuring this config was probably the hardest thing, theres so many considerations to take into account when structuring 1500+ lines of elisp in a literate manner and I still have not even explained every single code block!

Enjoy! :) Yep discord rpc within emacs is [really cool](https://imgur.com/Bj0DcFE.png)! You can enable it on startup with `(elcord-mode)` at the bottom of the `:config` section of the `use-package elcord` declaration. I personally toggle it with `M-x discord` though (`defalias`'ed to `elcord-mode`).

My main critique would be that you've misplaced focus regarding startup performance. You have all of the standard "shave a few hundredths of a second off my init time" optimizations, yet you load the Org files via babel on each init. It's faster to tangle the files ahead of time.

Thank you for this valuable feedback. If by tangle ahead of time you mean tangle the file once only then load the .el for every startup afterwards - how does one accomplish this? also how do you ensure that the tangled .el files are kept up-to-date?

Yes. Tangle it out to "(early-)init.el" and let Emacs load those files directly. You can add a file or dir local after-save-hook function to automatically tangle the file when it is changed.

Thank you very much! :) I'll add this functionality later on today after some research.

I heard this argument before and I am a little hit confused. Org-babel-load-file checks if the org file is newer than the elisp file and only tangles if it is. So it would only be slower after changing the config in the org file, or do you mean slower because the org package will be loaded?

> So it would only be slower after changing the config in the org file No, it's slower every time. That check has overhead. > slower because the org package will be loaded? This, too.

Was worth reading just for the saving clipboard on kill setq which I was missing.

Here's a [blog post](https://assortedarray.com/posts/my-init-org-setup/) on how I handle this if you're interested.

Thank you! I have a [tangle.sh](https://github.com/DiamondBond/emacs/blob/master/tangle.sh) now and I have a [bash alias to run the tangle script before running emacs --daemon](https://github.com/DiamondBond/emacs#tangling). I have changed all org-babel-load-file instances to load-file <the .el file> instead. [There's also some nice helper functions in my config that tangles for you](https://github.com/DiamondBond/emacs/blob/master/config.org#config). I have to say though, I have not noticed any improvements to the startup time (before: \~1.7s, now: \~1.7s), even so I think i will continue with this method of bootstrapping as it seems to pander towards correctness. edit I have found a [package called org-auto-tangle](https://github.com/yilkalargaw/org-auto-tangle) that automatically handles tangling upon save with the prerequisite of having to add `#auto_tangle t` to all .org files that you want to tangle automatically upon save.

Which gems did you find useful? (just curious)

For me, it was: - Kill async buffers - Camel to snake case - Config reload - Command line history

IMO backup system is still useful even when used for files under (or soon to be under) VCS. Time to time people do some actions that cause loses before change or file is added to VCS. One of the common reasons in Git is hard reset (which has an undesired effect of people fearing reset command, though it's useful and not always dangerous, but that's off topic). Not trying to persuade anyone, just keep that in mind and make a conscious decision before copying that snippet disabling backups.