I disabled them on previous machine with spinning rust. This
machine (hermes) with SSD has proven capable of handling much higher
filesystem throughput, so I'm pushing it to see how far I can go without
impeding experience.
titan and lapetus are first of two new Raspberry Pi Zero Ws.
While quite anemic and decidedly incapable of running modern NixOS, they
still run Debian well enough, and are still full computers in their own
right.
So they get hostnames, the first of two moons in solar system, starting
from Saturn (should last a while :p), by ascending order of their year
of discovery. After Saturn, it'll be Jupyter, Uranus, Neptune, and then
back inwards starting from Mars. Luna will be last (if we ever manage to
get that far :p)
emacs29-pgtk is now available from NixOS-unstable directly.
the overlay still provides some updates, like more frequent ELPA/MELPA
package updates, but they are incompatible with how doom manages package
updates anyway. I might think about bringin back the overlay without
emacs itself in future, but for now, I'm getting off the bandwagon.
The plan was and still is to get off of overlay and emacs unstable
completely. While the run was pretty good, I consider Emacs to be part
of my digital infrastructure now, and having it broken means bad news.
Removing overlay and going back to stable branch just means reducing the
number of moving pieces, having more eyes on common friction points and
faster resolution. Hope this works as well as I'm expecting now.
..by Mickey Patterson, of Mastering Emacs fame.
The package is supposed to provide finer and nicer structural editing
experience, aided by new treesit(*-ts)-modes, but currently, I use none.
The only tree-sitter mode I currently use extensively is nix-mode, and
it integrates using external tree-sitter module, so as of this commit,
combobulate is fairly useless for me.
Now, doom's development has slowed down significantly, and I foresee
problems on the horizon with these new hodgpodge of tree-sitter modules,
so we'll see.
This is an experiment to try out built in fast movement in org-mode, and
these keys are only active when the cursor is at the very beginning of a
heading.
Since movement within org doc has always been something I've sucked at,
perhaps this will help.
It is useful, but I don't find myself using it very much.
One nice thing is that it uses Emacs keybindings itself, so learning
anything new is not required, but I just don't find myself using it
really.
Maybe someday meow will have a good module with doom and then I will
like that. Oh well..
- ui/modeline module
- remove minions
- Disable anzu and evil-anzu packages
- Enable mu4e-alert because apparently doom-modeline supports it
- set the height to minimal required
- Configure to my preferences
The stock modeline still looks kinda sorta ugly, but I'm willing to give
it shot over the bare nano-modeline.
Hopefully this will also allow me to add some more customizations in there.
I've always known that doom uses dash.el and f.el underneath, and many
many other packages do too, but never really paid much attention there.
But after a (very) brief stint with Clojure, I'm liking the left->right
flow that these higher level functions offer. I've already started to
abuse them in Java, but they are much more natural in lisps. I can see
why Clojurians spam them everywhere.
I know that they are slower than the builtins, but using these higher
level APIs is such a nice development and reading exerience, that I'm
going to try abusing them more now. They are a bit out-of-place for
idiomatic elisp, but here we go.
To use ChatGPT from within Emacs. This removes the problem of having to
switch away from Emacs, as well as gives better prompt customizability
as API is more flexible than their stupid Chat interface.
Lets see how this one goes..
Devil intercepts and interprets ',' as Ctr. It seems to make sense, and
work quite well, especially because I can observe it not being much of
an annoyance just while writing this message.
Anyway, it has potential to reduce number of keypresses and especially
number of keypresses where both hands are involved significantly,
particularly around scrolling and movement.
I remember disabling this way back when trying out mu4e for first time,
but I'm kinda tired of horizontal splits and constant window height
adjustment. This will need some tuning, probably around column order,
but I think it will be doable.
I'm not sure whether the passwordless sudo is required, but I'm too
tired to test right now. Anyway, this works.
Also unsure on the statelessness of deploy-rs, but again, its simple
enough, didn't require changing anything else much and it works.
Perhaps some day, I'll see about trying out colmena for deploying
secrets, but until then, agenix is good enough for my needs.
Right now this fails, because what I assume is a failure with emulation
in WSL, but otherwise I'm linking the overall approach of reusing the
preconfigured nixOSConfigurations in the same flake, as well as
lightweight burden of configuration. Doesn't hurt that it is written in
Rust rather than Python.
Since Emacs 28+ upstream follow freedesktop standards, doom has started
recommending cloning emacs config to ~/.config/emacs rather than
~/.emacs.d.
This commit updated my config to be agnostic to this location, and
always uses whatever location is used by Emacs itself.
flyspell+aspell is doing perfectly fine job, but I wanted to try the
newfalngled Jinx thingy from minad. It is supposed to be faster, by
offloading spellcheck to enchant lib asynchronously, which in turn uses
different backends such as aspell, hunspell, nuspell etc, as well as
only doing spellcheck for visible text, rather than whole buffer.
Here, I am using aspell, because I couldn't get nuspell to work, but
aspell worked wonderfully.
I had to disable the existing spellcheck module in doom, but considering
jinx required very little config, I'm willing to give it a better shot.
Jinx is also likely to be better maintained than doom (which has fallen
behind in commit activity, thanks to Henrik being a busy bottleneck).
On another note, this commit is also a perfect demonstration of
cross-system changes consisting of both system libs as well as Emacs,
combining them, and changing both in single go. This has also reduced
mental calculations, as separate 'doom sync' is now not required, and
the only command I need to remember to deploy my system OR Emacs config
is 'sudo nixos-rebuild switch'. This is also why I'm now even more
reluctant to move home-manager to its separate repo. Monorepo for
personal config rocks!
While unlikely during most use-times, on new system activation, for e.g.
the doom binary will be absent because doom setup is run by manually
cloning its upstream. Checking this before will prevent unnecessary
activation failure and runtime editing.
All the grammars I need are already added by upstream (emacs-overlay),
except for tree-sitter-nix, but I can live with that.
This will save little bit of time while rebuilding emacs closure, and
will take me a bit closer to upstream.
Doom recommends this, and I had a habit of it anyway.
This takes away some anxiety because now I know for sure that doom sync
has run on every doom config change as well as every NixOS config change.
This makes managing two distinct repos unnecessary, and only single repo
is required.
Since doom config repo was intended to be public anyway, there are no
secrets (I hope).
Pros are being able to deploy doom configs via single repo, which might
come in handy in future.
Cons are the need to redeploy NixOS config again just to deploy Emacs
config. Another config is increased Emacs startup time, because now it
has to traverse through the symlinks to nix-store to get the file
contents.
But, this is an experiment worth trying, so let's try this. Doom's setup
is still done imperatively via its own installer, but the config itself
is deployed via NixOS. We'll see how the trade-off goes.
Now that the Emacs unstable branch has switched to 29.0, I am getting
off the wild ride of master. Hopefully doom will also stablize pretty
soon, and this was planned all along.
I like the default behavior of magit, but after increasing font size it
suddenly started opening from bottom instead of from the right.
There's probably some config somewhere to decide this (probably
line-length limit), but for now I'm not going to spend much effort on
it. doom's popup rule macro is good enough™.
- Comments are brownish rather than yellow
- Strings are more intense green
I'm digging the comments, but strings are sort of too pronounced
compared to rest of the code. Might want to revert to orignal
green-cooler if it gets distracting.
Some component in ox-zola+ox-hugo+zola was making markdown not be
rendered properly to HTML. I had no time to figure it out so Hugo was
it.
ox-hugo is well maintained by Kaushal Modi and others, has much more
widespread use, is well documented, and Hugo even uses it automatically!
Overall, I'm liking the result, and keeping it.
I moved my blog to Hugo. Zola's markdown rendering wasn't really
working, and I didn;t want to debug that at this moment.
Hugo worked much much better, with no intermediary step for converting
to md, as it supports orgmode by default.
partly inspired by
https://christiantietze.de/posts/2023/01/modus-themes-v4-changes/
- Use variable pitch font in some org-agenda constructs
- Enable mixed-fonts
- Use medium and italic for prompts
- use medium weight instead of semibold for default org headings
- Use :custom keyword in use-package config
This is a major, breaking change.
Nearly all the variables are gone, and face-by-face override is
necessary. Modus-themes are now a theme-engine with some reasonable
defaults. This makes it more customizable, but also needs more tweaking
than before and knowing more about Emacs faces.
Anyway, I got to a reasonably close approximation of what I had before,
but there are things remaining. Namely, completions, org-blocks,
org-agenda bolds and hl-line brightness.
But, for now, its mostly good enough.
This is the ultimate solution for weird intricacies of Rust programs
or SBCL needing OpenSSL for compiling stuff, or pre-compiled internet
binaries (not that they're good..) needing specific libs in specific
places that don't exist on NixOS.
While this makes the system less good, it does make it a more
accommodating citizen in the Unix land. This is also a lot more
declarative than any other system out there, so that's an added benefit.
If this works out as advertised, this is going to change a lot of things.
- Add arxiv-citation
- Download arxiv PDFs
- Automatically add bibtex entry to specified file
- Minor modifications to Citar config
- Configure citar-org-roam to not use any subdirectory
The commit line length in Doom by default is 80. However, because of my
current laptop screen and split screen editing of commit message in
magit is configured, the line endings happen very awkwardly with single
character on newline. This is generally not an issue, but its just a
nagging thing that I personally do not like.
One of the obvious fix is to simply set the commit message line length
limit to 72 characters as does Linux kernel (and hopefully other GNU
projects, possibly including Emacs itself). This doesn't make too much
difference in usability, while preserving the aesthetics on my laptop
display.
Because this utilizes both the hook and a check for buffer name, this
should not modify the line length for any other buffer and remain at 80.
Like Prot, I have concerns on use-package DSL becoming a problem, but for now, I
find the declarative nature of it to be a good thing and consider it worthwhile.
