Personal frustration and the biggest time waster in my life (comparable to video games). Please, turn away and retain your sanity. Otherwise you might end up tracking all your tasks, notes, thoughts and wine in Emacs.
Aside from configuring Emacs for my personal needs, this project has several additional design goals in mind.
- Byte compilation must succeed without any warnings.
- Linter must be happy.
- Loading must be fast (less than a second).
- Ability to write applications that could be separate packages, but are too personal or too experimental to be worth the effort.
- Ability to write and run tests.
In order to achieve these goals, the following approach is used.
- All lisp files are divided into 3 categories.
initfiles that configure built-in and external packages viause-packageinterface. They must notrequire(e.g. eagerly load) any packages that should be loaded lazily. Allinitfiles are required by maininit.el.configfiles that contain configuration variables or constants. Safe torequirefrom any place as they do not contribute much into loading time.libfiles that should not be required directly from other files and should be loaded viaautoloadsfile generated during build process. These files are fine torequireany packages they need to make byte compiler happy.
- All the build process, consisting of bootstrapping,
autoloadsgeneration, byte complication, linting, testing and upgrading is managed by Eldev. See Eldev file details. - Life cycle of configurations are install, upgrade and test. They are executed using eru script. Read further for details.
- straight.el is used as a package manager instead of
package.elor any other system. While being pretty complex, in my opinion it is the most stable and reliable package manager when it comes to installing and upgrading packages. - For better
flycheckexperience there is flycheck-eldev. - elisp-lint is used for linting, some custom rules applied (for
package-lint). - Testing framework of choice is buttercup.
Section is under construction. Please return in -2147483648 seconds.
At the moment of writing this, I already have more than 10k org files. Most of
them do not contain any TODOs. When org-agenda is built, it needs to traverse
all these files. So the idea is to build org-agenda-files dynamically before
org-agenda is executed by marking files containing TODOs on file change and by
using wonderfully fast query capabilities of org-roam. You can read more at
d12frosted.io.
Points of interest:
lib-vulpea-agenda.elvulpea-agenda-files-update- a function that updatesorg-agenda-filesto contain only files marked withprojecttag (e.g. containing TODOs).
lib-vulpea.elvulpea-project-files- a function to query the list of files marked withprojecttag (e.g. containing TODOs).vulpea-ensure-filetag- a function that adds or removesprojecttag from current buffer depending on existence or absence of TODOs.vulpea-setup-bufferandvulpea-pre-save-hook- functions that executevulpea-ensure-filetag, used as hooks.
init-vulpea.el- module that sets up all hooks (e.g.org-agenda,before-saveandwindow-buffer-change-functions).
It is described in greater details at d12frosted.io, but in short, whenever a
meeting starts, I want to select a person I have a meeting with and capture
notes under Meetings outline in that persons file.
Points of interest:
lib-vulpea-capture-elvulpea-capture-setup- a function that sets up capture templates.vulpea-capture-meeting-template- a function that prompts to select a person and depending on the result returns different templates.vulpea-capture-meeting-target- a function that picks a target for captured note depending on selection fromvulpea-capture-meeting-template.
I have already covered this topic at d12frosted.io. In short, init-elpa.el
file contains functionality to automatically retry raxod502/straight.el
operations. Take a look at definition and usage of elpa-straight-with-retry.
Not so long ago (few years ago?) I’ve started to take notes while I am reading books, articles, listening to videos, or completing courses. Previously it was a scattered mess (mostly left in my e-reading application), but now I have it all under litnotes directory in my Org directory.
In order to list all my reading notes, I’ve built a solution based on publicimageltd/lister, vulpea and org-roam libraries. Take a look at lib-litnotes.el file, your entry point is litnotes function.
Right now this buffer has minimal functionality:
- List all litnotes grouped by status (see
litnotes-status-values). - Configurable faces for each element.
- Tab expansion to hide or show specific group (e.g. status).
- Visiting note (
TABvisits litnote in other window,RETURNvisits in current window). - Assign status to a note at point (by default,
s).
More functionality to come:
- Ability to change default grouping (e.g. by content type, author or no grouping at all).
- Interactive sorting.
- Interactive filtering.
This is a playground for building more complex solution to support something like vino.
The vino library is far from having all the features I want it to have, but v0.3 is mature and rich enough to use it to keep record on wines. Things that are either not well designed (from user perspective) or are too tied to my personal usage find their place here, in my personal configurations.
There are several interesting functions.
There is an option to tell vino library how to calculate availability of vino-entry. There is no solution out of box (yet), but vino-availability-fn (together with add and sub) allow to easily implement inventory solution on your own. And for that I am using hledger. You can grab the code from lib-invetory.el file, nothing overly fancy there.
Now, having vino, vulpea and lib-invetory it’s fairly easy to implement a function that displays wines in my cellar - vino-balance-display, you can find it in lib-vino.el.
I am not statistical expert, but I love to see numbers related to wine consumption. It’s amazing to see a bigger picture after I put so much effort into writing down most wines I taste. The ‘bigger picture’ is calculated on some period (custom or predefined) and includes (but not limited to):
- General stats like wines consumption, rating data, price data and QPR data;
- Per country stats;
- Per vintage stats;
- Per colour stats;
- Per carbonation stats;
- List of all ratings in the given period.
My plan is to provide functionality to export all this data (probably) with images and graphs.
I am using part of this library to generate reports on wine tastings I organise in Kyiv. You can find some stuff on my Dropbox (mostly in English, but some documents are in Ukrainian). Hopefully soon my Barberry Garden will get its own site.
Checkout vino-stats.el module for implementation.
All requirements are installed by eru. But the full (and dramatically huge)
list of dependencies is here:
- Emacs 29 or higher - installed by
eru install system. - Eldev - installed by
eru install emacs.
For OS X users I recommend to install emacs-plus (who would guess?) - GNU Emacs with some sane defaults, available via brew package manager, though in general I prefer (and highly recommend) using nix or macports instead of brew.
$ brew tap d12frosted/emacs-plus $ brew install emacs-plus@29
You are free™ to use whatever Emacs variant you wish to use, though I don’t give any guarantees that it will work with these configurations. In case you wish to investigate more on this topic, please refer to this answer.
$ eru install emacsInstall Eldev.
$ eldev_bin=$HOME/.local/bin/eldev
$ curl -fsSL https://raw.github.com/doublep/eldev/master/bin/eldev > "$eldev_bin"
$ chmod a+x "$eldev_bin"Bootstrap Emacs configurations, compile them and lint.
$ cd "$XDG_CONFIG_HOME/emacs" && make bootstrap compile lint$ eru upgrade emacs$ cd "$XDG_CONFIG_HOME/emacs" && make upgrade compile lint$ eru test emacs$ cd "$XDG_CONFIG_HOME/emacs" && make test