The idea is that every task should be shown as an MDL "card" and have
some sort of associated action (probably more than just a click, but
that I'll look at ...).
Tasks are coloured based on their current "urgency".
Emacs just controls everything now. Why not!
Rather than using the builtin NixOS support for EXWM I've added a
custom snippet that takes care of the launching. This assumes that the
user launching the session has my emacs configuration installed, which
I, in practice, always do.
* remove setup of i3wm (until I'm comfortable using exwm I will keep
the i3 configuration files around)
* disable compton (exwm brings its own compositor)
* disable auto-starting of emacs user service
* enable & configure exwm (also see correlating commits in my emacs.d
repository)
I don't actually use all that many emacs navication keys in X11
applications - but being able to copy & paste is nice.
Overrides the default set of input simulation keys for EXWM with
slightly fewer and more sane bindings.
The default elblog route (/{article-name}) can now be extended with
user-supplied routes by overriding the elblog-additional-routes
customize variable.
This variable takes the same format as the alist supplied to
elnode-hostpath-dispatcher.
The prefix `/en` has been dropped from the default handler because
that only existed to be compatible with my old blog, which is no
longer required as it can now be handled with a custom legacy route in
my personal blog configuration.
* adds a hash-table stored in a variable called `elblog-articles` that
defines a map of article names (used as URI fragments) to file names
of org-mode files
* adds a custom variable `elblog-article-directory` which must be set
to the base path of the org-mode files representing elblog articles
* refactors the article-rendering functions to look up articles in the
articles hash-table and renders them from there
After this change elblog is almost functional as a blog software, only
missing index generation.
When creating a large number of queues the message queue rlimit may be
reached (see mq_overview for details).
This commit adds an `mq rlimit` function that displays the current
rlimits and an optional `--rlimit` flag to the `create` command that
can raise the rlimit when required.
