blog of axlefublr

nirism

Axlefublr — Mon, 02 Mar 2026 00:00:00 +0000

I've been using niri for a bit over a year now, and yet still I have a soft cap of windows I'm able to open before I'm completely lost. Almost assuredly a skill issue on my part — I know people who have around a HUNDRED windows open at a single time, so there must be some way for me to gain the power too, right?

Recently I made some pushes on configuring my workflow to allow me to manage more windows, easier.

overview</a></h1>

When the overview first came out, I was excited about it but towards my friends, not towards myself. It didn't sound useful to me. I added a hotkey for it sure, but then continued to basically never use it. What's the issue then?

Part of it is effort. I open the overview and sure, I see some windows around the current one, but not that many. It helps me find myself a bit, but with the limited value it provided it was hard to mentally argue with myself to press the separate hotkey for it.

You can, however, change the zoom level of the overview, to be able to fit more windows at once. I thought at first that it's not that good of an idea because then there's less detail for me to use to discern windows, but no! Especially thanks to another thing I'll talk about later in this blog post, reducing the zoom level has made the overview much more useful to me.

I configured the zoom to fit ~2.5 workspaces both above and below. In effect, now when I open the overview, I can see almost all of my opened windows! Finally, the overview is doing its job — being an overview.

In contrast, the default zoom level looks ridiculous, in how much less useful it is. But there's reason for it being that way — you see, all of your window-managing hotkeys do work in the overview as well. You can close, consume, expel, move windows, workspaces, and more. Normally that can get a bit confusing, especially if you try moving workspaces (no animation for that) — but if you do it from the overview, suddenly things are a lot easier to visually track, because you have a bigger surrounding context. Then with most people only using 1-3 workspaces, you don't need to zoom out that much to get the benefit, so I'm guessing that's why the default zoom is so close.

For me though? Zooming it out was the solution.

Secondly, the hotkey I chose for it at first was kind of eh. There's an idea I like to talk about in Hotkey™ Theory™ — “sequentiality”. The hotkey should be pleasant and ergonomic not just in a vacuum — when thinking of the hotkeys you create, you should also consider what other hotkeys may come before and after it.

With the overview, right after opening it I might move ←↓↑→, to different windows and workspaces. With moving bound on Meta+hjkl</kbd>, and the overview being bound on Meta+o</kbd>, the sequentiality is poor. I can't quite move to the window on the right, right after opening the overview — I must move my finger from o</kbd> to l</kbd> first. There are much poorer sequentialities out there so this comparatively is not a big deal, but it was still contributing to my “eh”ness about the overview.

I rebound it on Meta+Space</kbd>, and now that feels a lot better. Normally I dislike using Space</kbd> in hotkeys because of how massive it feels to press, but for the overview that actually works in its favor. It already feels like a “large” action, so pressing a “large” key to get access to it makes sense to my fingers. And then of course the better sequentiality. Right after pressing Meta+Space</kbd>, I can without moving any of my fingers, move ←↓↑→ to windows and workspaces, at max comfort!

After doing these two changes, I actually started seeing myself use the overview a lot more. Really nice tool for “finding yourself” so to speak.

workspaces</a></h1>
The next part that makes it easy to get lost, is how many windows I may open on a single workspace. I start some sort of workflow; let's say I'm working on my gtk theme</a> (probably soon discontinued). I'll wanna open gtk3-widget-factory</code>, then maybe another gtk window where I'm testing something specific I can't find in gtk3-widget-factory</code>, a terminal for pastel</code>, a terminal where I wanted to run some one command and forgot about, a window where I'm checking the docs on waybar</code>, “whoops I want to check what chores I need to do today”, and so on and so forth.
A given workflow may create a bunch of windows. A couple of them are valid, but some other ones are in the way. The “some one command” terminal needed to exist for a second, but afterwards it remains to be clutter. If I realize I want to run another some one command, by that point I might've forgotten that I already have a terminal for that, and so I'll likely open another one. This specific usecase I'll talk about in a later section, but what is very of interest for now is the doc window on waybar and chore tracker.
It would be pretty nice to have auxillary windows like that to all be in the same spot, rather than riddling the workspace where I'm working on a given thing.
In niri, when a window spawns, it spawns on the current workspace. You can make a window rule to make it open on a different workspace, as long as that workspace is named. And so, I create 5 workspaces, all named: one, two, three, four, five. Pretty much just so that I could use them in window rules.
I considered at first to then make hotkeys that activate a specific workspace, but soon gagging from the memories of awesome wm, I realized I quite dislike it. A real nice thing about niri is its dynamicness; I want to retain that part and play into it, so my main form of navigation remains directional.
One change that I did add though, to aid moving across now more workspaces, are hotkeys to go to the first / last workspace, and hotkeys to go to the first / last column. The latter ones I already noticed myself wanting many times in the past, but the workspace ones are a bit more questionable in terms of usefulness.
So, my named workspace layout is as such:
three two one four five</code></pre> Workspace one is the middle one, the “first” (top) one is three, the last (bottom) one is five. I still can create more workspaces if I need them — I simply create a window on the automatically created workspace beyond three</code> or five</code>. Playing along niri's dynamicness. Workspace three will now hold a bunch of my “status” windows so to speak. Currently on it I have open my chore tracker, calendar, a reminder thingy, a bluetooth tui, and a helix where I'm calculating my earnings. All except the last one I window rule to always open on that workspace, so now when I suddenly decide to check what chores I have to do today while working on some project, that window will not get created in the midst of a bunch of other stuff, but instead get moved onto the workspace specifically for status windows, helping me stay more organized.
Similarly, documentation windows^{1 </a> I window rule to always appear on workspace five. Way easier to keep track of, not get lost in, and eventually clean up.}
</hr> </a> What named workspaces also allow me to do, is create more windows on startup. Previously I wouldn't want to do that, because a bunch of the windows would be created on the main workspace, when I prefer to keep them on some other one. But now I can actually express it! On login, the reminder thingy, chore tracker, calendar is created onto workspace three. Yazi opened in the anime directory and anki on workspace four. Yet on the main workspace, workspace one, I still start out with my terminal window and the browser. Less things to have to create manually! Pretty nice. togglies</a></h1> Windows are automatically grouped together now thanks to named workspaces, but the issue of duplicates remain. The chore tracker is started on login, but I also have a hotkey to open it. It's plain easier to press that hotkey than to navigate to the existing window, and afterwards I may forget to close the new one, resulting in a duplicate that will help me get lost. I have quite a bunch of hotkeys that create some window, actually. And so, I decided to make their behavior a bit smarter. If the window doesn't already exist, it's created</li> If it does exist but isn't focused, it's focused</li> If it is focused, the most recent window is focused instead.</li> </ol> I expressed this via a fish + nu script: #!/usr/bin/env fish set -l wheres for arg in $argv[..-2] set -a wheres "| where $arg" end nu --no-std-lib -nc " let found = niri msg -j windows | from json $wheres if (\$found | is-not-empty) { if (\$found | any { get is_focused }) { niri msg action focus-window-previous } else { \$found | first | each { niri msg action focus-window --id (\$in | get id) } } } else { niri msg action spawn -- $argv[-1] } "</code></pre> How to convert it to bash + jq is left as an exercise to the reader. The full command to give the chore tracker toggly behavior, for example, looks like this: find-or-make.fish "app_id starts-with foot" "title == loago-tracker" "footclient -NT loago-tracker fish -c loago_tracker"</code></pre> First, an array of nushell where</code> checks to identify the exact window. And as the last argument, the command to use to create a new window. Now whenever I want to check my chores, I press h↓s</kbd> once to take a looksie, then press h↓s</kbd> again to go back to what I was doing. No new window is created if the tracker already exists, no mess is created for me to get lost in. I used to have this kind of workflow back on windows with autohotkey actually. Not sure why I haven't replicated it in so long, I remember absolutely loving it. I get to love it again 😌 A lot of my windows I can now target directly. Most windows on workspace three, for instance. Which makes me realize that there are only a few windows on that workspace that I'd want to focus via normal means. So if I put all of the “other” (without a direct hotkey) windows at the start/end of the workspace, I can use my hotkey to go to the first workspace followed by a hotkey to go to the first/last column, and that way I can quickly jump to the “other” windows that are otherwise maybe annoying to reach. The windows in the middle are then ones that I have direct hotkeys for, so them being more difficult to reach, compared to the first/last windows, is not a big deal. The first/last column and workspace hotkeys I all have on we↓</kbd>, so the sequentiality of going to the first workspace and then moving to the start of it is fantastic. Some windows prefer to be closed rather than stay open, though. bluetui</a>, the bluetooth tui I'm using, likes to get fucked up if left unsupervised, for some reason. So instead of just toggling away from it, I'd want to close it. So this ↓ If it is focused, the most recent window is focused instead.</li> </ol> </blockquote> I want to also close the window afterwards. This idea is still in the process though, I'll either add some flag to the find-or-make.fish</code> script above, or I'll make a separate hotkey to express the concept of “switch to the most recent window, close the window you just switched away from”. “Doesn't this already happen when you close a window?” you might rightfully ask — not quite! The most recent window on that workspace is activated, rather than the global most recent window. Reasonable behavior, mind you, but keeping recency correct has recently become significant for me, which we'll talk about later. The biggest usecase for find-or-make.fish</code> is a toggle terminal. All those one-off commands I might run and come back from? I can now press Meta+Enter</kbd> to activate my permanent-staying toggly terminal, then press Meta+Enter</kbd> again to come back to where I was. In the past, I had a hotkey that created a floating terminal, for a similar usecase to this. It resolved the need somewhat, but had some downsides. Due to it being floating, I kinda need to “handle” it immediately — if I don't close it after I run my command, it'll be annoyingly in the way. That's part of the intention yes, but there are some cases where the command I run takes some time to complete, and I don't care to wait for it to complete — I just want to make sure I start it. Other times, the output of the command is unbearable to view in the small floating window. Making the floating window big instead makes it kind of confusing to work with. So a normal ass terminal I toggle into is a much better approach I think 😼 As a side benefit, I get to keep old output, for me to possibly look at multiple times, rather than discarding it every time by closing the window. alt tab</a></h1> Is another niri feature I was excited for, but for my friends — not myself. But also, I was surprised that it became part of niri upstream. In niri, to get to windows you almost always necessarily focus multiple windows on the way, so alt-tab functionality sounds so off, right? The small but ridiculously important caveat here is debounce — a window is not added into the most recently used list if you've spent less then x milliseconds focusing on it. You can configure the x of course. But the thing is, I don't really think about my windows in terms of recency, I think about them in terms of geography. Where they are, rather than what was the window I was just using. Another skill issue of mine, I bet! Just like many other things I trained my brain to be able to do, home row mods</a> being the wackiest one, I can probably train my brain to think in the recency plane as well :3 I've tried using the feature once before in the past to no avail, but this time is a bit of a changed circumstance — now that I always have 5 workspaces (or more!), to move through, using the recency plane to switch between them quickly becomes a lot more juicy. Imagine I'm on the second workspace, open the docs for something, and want to move back. Currently I'd need to move to the above workspace thrice, or go to the first one and move down once. Neither are particularly pleasant! But with alt tab, I can jump back in one fell swoop, with a nicer semantic to boot — what I want to express, after all, is “bring me back where I just was”. When I realized that that's what I mean, I was sure my brain would adjust to the recency plane pretty well. But there's some more configuring work to do on alt tab before I find it truly viable. As I started using it, I very quickly noticed that it's hard to anticipate the next window in it. When you select the window on the right of your screen, you only see a small sliver of what the next window is. Basically never enough to be able to tell ahead of time how many “next window please”s it's going to take to get to the window that you want. To see what the next window is, I need to “next window please”. Then if I went too far, I need to manually go back 🙄 I realize that what I want is for the selected window to always be centered in the alt tab ui. And that's exactly what I did! </video> You can find the patch in my niri fork</a> or in this thread</a> on the niri discord server</a>. Now as I go through windows in the ui, my brain can preprosses how many more times I need to press my hotkey, as I can see a lot more windows ahead of time. As opposed to pressing the hotkey, going “nope, not that one”, and pressing it again — which is an annoyingly start-stoppy workflow. Notably, I reduce the zoom level here too, to be able to see more windows at once. Here, losing the detail by zooming out matters reasonably more than in the overview. To make the tradeoff worth it, I have some tips and tricks I'll talk about in the next section. Another feature alt tab has to try to be less annoying, is that the ui only appears after x milliseconds. Reasonable once again, but what I found is that I'm not that annoyed about the ui popping up every time. Yet it appearing immediately is actually really useful because I can start the brain preprocessing step earlier, helping me navigate in the recency plane better ✈️ Rather than it being only a switcher, it suddenly becomes another form of overview — but instead of geographical, it's based on recency. I'm still human though, so for the cases where I switch between only two windows over and over again, I gave myself a separate hotkey that does just that, using the focus-window-previous</code> action that doesn't even use the alt tab functionality (and hence ui). This also means that it doesn't have the crucial debounce, but should be worth it still. makeup</a></h1> When all of your windows are the same size, they become hard to distinguish. Especially when (almost) all of your windows are just terminals: text just looks like text a lot of the time. But if they are of different sizes, they are a lot more immediately distinguishable, in alt tab, overview, and even just as you scroll through the windows naturally. Sometimes that even results in you fitting more windows at once, as a side benefit. I have hotkeys that change a window's bigness by 5%, and for a while I underused them for reasons I didn't quite get. I use home row mods</a>, and so to effectively hold some key, I need to tap it and then hold it. Normally not a big deal, but for incremental hotkeys like 5% bigness changes, you really want to be able to hold them immediately. With a low repeat-delay and high repeat-rate, suddenly that turns into a fantastic experience. I rebound them on keys that do immediately get the hold behavior, rather than being tapholdies, and now I can ergonomically whoosh windows to my prefered size, followed by a few small correcting resizes. Wonderful. Especially (more realistically, mostly) for terminal output, I might run some command and wanna store it for later. I run the command, resize the terminal to only as much space as it needs (maybe making it bigger instead, actually!), then maybe throw it on workspace five, to get to later. There are a lot of windows that I want to always have the same size, though. The reminder, chore tracker, yazi for anime, etc etc. So! I can create window rules for those windows, sizing them some size automatically. On the path of doing that, I also need to name those windows something specific, so that making window rules for them is straightforward. But the incidental benefit I get from it is that now a lot of my windows are named more usefully. When I see them in alt tab, not only does their size help me preprocess them, but also the window title I see makes things a little easier. Taking care of your sizes and titles is the big reason why zooming out even the alt tab ui, I found to be a worthy tradeoff. </hr> </a> With all of these changes, I'm starting to get more comfortable managing more windows at once, and don't feel as forced to close windows immediately. Still trying things out, but I think this has been an awesome push to make use of moar power that niri has :3 footnotes</a></h1> ^{1 </a> I have hotkeys that open man …</code> / … --help</code> / nu -c '… --help'</code> in a new window, either through helix or}ov</a>.

rust for... scripting? pt. 2 Axlefublr — Fri, 13 Feb 2026 00:00:00 +0000 In my previous blog post</a>, I arrived at a rust “scripting” system that I was quite satisfied with :D But since then, I took upon a journey to learn nushell, and therefore was using it for a lot of my new needs. For some of them, nushell isn't even the most appropriate tool, but finding reasons to use the language so that I could learn it better is a technique I make use of all the time. One day, I realize I want to edit a rust “script” that I already have. Wait... how do I do this again? There's a workspace directory, that is symlinked to one of the directories in the cache directory, glued by a bunch of harps. Right... When I zoom out, I realize that the system that I have created is a bit overly complicated. Coming back to using it again, it isn't immediately obvious what I'm supposed to do to edit existing work, and amn't quite sure how I'm supposed to start new work. Initially, I made the system to ease in the barrier of entry towards making a new rust program. I succeeded in doing so somewhat, but there is still a bit of a barrier. I can design this to be simpler, surely. And thanks to the suggestion of my friend remrevo</a>, turns out I make it better too. The core want that I want to address is that creating a new “script” contains everything it needs in a single file. More or less. Then, I want to store all of those scripts more or less in the same place, so that they are pleasant and easy to manage. And, I want to name the scripts like I would be naming scripts, rather than how I would be naming projects. Finally, the resulting binary should have the .rs</code> extension in its name, so that rust “scripts” are easily differentiated from “normal” binaries, helping me name them neglectfully. Putting a consume.rs</code> binary into $PATH</code> is free — almost no chance something else I'll be using in the future will collide with it. Putting a consume</code> binary into $PATH</code> is a lot more questionable. Pretty dang common word! I'd need to take a real think before choosing such a name, and I don't want to think! Now, I keep using the word “script” but at this point it's lost most of its meaning. I've been fine with having a compile step for a while. I'm okay with having files around it to make it work, but I really don't wanna create a whole ass another directory for a new “script”. And I'm not actually running the file, I'm running the binary that just so happens to be named the same as its source code. So I say “script”, but I mean “an easily creatable rust binary”. Doesn't quite roll off the tongue as easily though, so I'm going to keep using the word script. Rust provides me kinda exactly what I want, turns out. In a rust project, you create a src/main.rs</code>, and that is the entry point to your binary program. You may then also (or instead) create a src/lib.rs</code>, and that's the entry point to the library side of your program. You can have both at the same time, or only one of them. But you can create another special thingymabop: src/bin/</code>. You can create rust files in that directory, and each individual file is its own binary entry point, like src/main.rs</code> is. src bin consume.rs zat.rs Cargo.toml</code></pre> This turns out to be much more fantastic than the system I would've designed would be. In a normal project, you just have one binary, and it's automatically named the same as the project is called. Some projects, though, can produce multiple binaries. Yazi produces yazi</code> and ya</code>, nushell produces nu</code> and a bunch more other binaries for plugins. In those projects, the “entry points” are defined manually in Cargo.toml</code>, but with srs/bin/</code> we don't need to bother doing that! A file with an .rs</code> extension existing in src/bin/</code> makes cargo automatically register it as a binary entry point. So, to run or compile a “script”, we refer to it with the --bin</code> flag. If I want to cargo run</code> the consume.rs</code> script, I do cargo run --bin consume</code>. Pretty straightforward! To make this ergonomic to use, I can put :sh cargo run --bin %(buffer_stem)</code> into a command harp</a> in my helix ^{1 </a> . With it, I can express “run the script I am currently looking at” (in my editor), on a singular hotkey that I can put into my muscle memory.} Then to “release” a script, I first do cargo build --release --bin %(buffer_stem)</code>, and then cp</code> over the resulting binary into the directory where I hold my wks binaries, appending the .rs</code> extension at the end. Pretty simple also. Especially when compared to my previous wks system! There, to edit an existing script I would need to import it from a file into the “workspace” directory and use a fancy exporting script so that the compilation is targeted from the cache. If I wanted to create a new script, I would need to first check if I haven't forgotten to export the changes in the workspace directory and then use the once again fancy script for bringing in a blank slate, and symlinking everything into place. Wanted to make an ad-hoc binary for a laugh</del> testing? I'd need to point it to a path where the source + Cargo.toml would be exported into, even when I don't care to actually store the testing source code long-term. It was a mess! In the new system, I just create a new .rs</code> file in src/bin/</code> and I'm done. </hr> </a> Next thing that you might see in the file structure, is that all the binaries share a singular Cargo.toml</code>. This is fantastic! Once I cargo add</code> some dependency, all of my binaries get access to it. The same version is used for all of them, and crucially the same compile artifacts are used across all of them. So once I compile clap</code> once, I won't need to wait for it to compile for my next binary that also uses clap. This is also neat for my storage space, as rust compile artifacts like to balloon quite a bit! The binaries also share a single library entry point. src lib.rs bin consume.rs zat.rs Cargo.toml</code></pre> This in particular unlocks some incredible power! I can write abstractions and helpers in lib.rs</code>, that I then continue on to use across a bunch of different binaries. Where at first, creating some sort of binary might be a pain, after a bunch of iteration I'll have made the experience so nice for myself that I might then reach for rust out of desire, not only out of performance needs. In the old wks system, the default template for a new rust script contained a long paragraph of use</code>s, for structs and traits that I'm very likely to use in a script. Having to import only what I need gets annoying quickly if I keep on needing the same things, after all. But now, I can compact them all into a single use wks::prelude::*;</code></pre> To do this, I create a new module in lib.rs</code> called prelude</code> pub mod prelude;</code></pre> I create prelude.rs</code> src lib.rs prelude.rs bin consume.rs zat.rs Cargo.toml</code></pre> And go ham, pub use</code>ing all the imports that I feel like I need most of the time: #![allow(unused_imports)] pub use anyhow::Context; pub use anyhow::Result; pub use anyhow::bail; pub use anyhow::ensure; pub use clap::Parser; pub use std::borrow::Cow; pub use std::collections::HashMap; pub use std::collections::HashSet; pub use std::env; pub use std::fmt; pub use std::fs; pub use std::fs::File; pub use std::fs::OpenOptions; pub use std::io; pub use std::io::BufRead; pub use std::io::Read; pub use std::io::Seek; pub use std::io::Write; pub use std::ops::Not; pub use std::path::Path; pub use std::path::PathBuf; pub use std::str::FromStr; pub use std::sync::LazyLock;</code></pre> And now all of those modules, structs and traits are all in scope immediately, in all of my scripts. </hr> </a> Kind of by habit I still made myself a nice alias to make reaching existing and creating new scripts more ergonomic, but it's not even that needed honestly. I have this simple template file: #![allow(unused_imports)] #![allow(unused_variables)] #![allow(dead_code)] use wks::prelude::*; fn main() -> Result<()> { println!("{}"); Ok(()) }</code></pre> That I store in the repo. I then make a fish alias wks</code>: function wks set -l prevdir $PWD if test "$argv[1]" cd ~/fes/wks rsync ~/fes/wks/template.rs ~/fes/wks/src/bin/"$argv[1]".rs helix ~/fes/wks/src/bin/"$argv[1]".rs return end cd ~/fes/wks/src/bin set -l picked (fzf) test "$picked" || begin cd $prevdir return 1 end cd ~/fes/wks helix ~/fes/wks/src/bin/$picked end</code></pre> With no arguments provided, it opens fzf</code> for me to pick an existing script to edit, and then opens it in helix from the root of the wks</code> project. If I do provide an argument, that is the name of the script that I want to create (without the .rs</code> extension) by copying over the template file. I intentionally don't safeguard myself from overriding an existing script this way! I have a test.rs</code> script that I gitignore. It's meant for various ad-hoc checks and tests. Any time I want to start testing something from a clean slate, I just wks test</code> and I'm there! Whatever the test script used to be before then is wiped clean, and I can immediately get to work. Recently realized how nice this is in practice. I was working on a new helix feature as usual, and for some reason the.get(1..)</code> was returning me None</code>, despite the</code> being at least two characters long (in fact more). I do a simple wks test</code> and check out the test case in a “pure” environment, unlike helix, and was able to figure out the core of the issue ^{2 </a> really quickly :D It was such a pleasant workflow!} The repo that holds wks</a> is public! Check it out, and maybe make use of the idea for your own nice collection of itty bitty rust “scripts”. footnotes</a></h1> ^{1 </a> “My” is very significant there, buffer_stem</code> is a custom command expansion in}my helix fork</a>. Normally you would need to use %(file_path_absolute)</code>, converting it into its basename without the extension in one way or another. ^{2 </a> The first character was €</code>, a multibyte character. get</code> on a &str</code> returns None</code> if you try to index inside of a multibyte character. To work around this, I used the.char_indices().nth(1)</code> to get the index of the second character, and then used that value in the afforementioned get</code>.} erotic meta feet Axlefublr — Tue, 11 Nov 2025 00:00:00 +0000 I just figured out a longterm annoyance I've been having with how kanata does layers, and I want to share my findings with you. Sequences of key presses and releases are really hard to mentally parse when in word form, so I will establish a syntax for expressing those. e↓f</kbd> — hold down e</kbd>, and while still holding it down, press and release (i.e. tap) f</kbd>. e↓f↓j</kbd> — hold down e</kbd>, and while still holding it down, also hold down f</kbd>, and while still holding both e</kbd> and f</kbd> down, press and release (tap) j</kbd>. e↓[jk]</kbd> — while holding down e</kbd>, individually tap j</kbd> or k</kbd>; maybe repeatedly. e↓f↓w↓[jk]f↑[jk]</kbd> — one after the other, start holding down e</kbd>, f</kbd>, w</kbd>. While holding them all, tap j</kbd> or k</kbd> however many times. Then, release f</kbd> but not the other two held keys. While continuing to hold e</kbd> and w</kbd>, tap j</kbd> or k</kbd> however many times. efw↓[jk]</kbd> I hold down e</kbd>, f</kbd> and w</kbd> in unspecified order and tap j</kbd> or k</kbd>. So this might be one of: e↓f↓w↓[jk]</kbd>, e↓w↓f↓[jk]</kbd>, f↓e↓w↓[jk]</kbd>, f↓w↓e↓[jk]</kbd>, w↓e↓f↓[jk]</kbd>, w↓f↓e↓[jk]</kbd>. This notation implies that the order of the presses shouldn't matter. our setup</a></h1> I'm going to create an example config to explain things with. We will have three layers: meta, erotic, feet. You enter the “meta” layer with w↓</kbd>, the “erotic” layer with e↓</kbd>, and the “feet” layer with f↓</kbd>. I name them funnily so that their absurdity can help you make them apart more easily 😌 “Ah yes we have layer a b and c” would get confusing quick imo. (deflayermap (default) w (layer-while-held meta) e (layer-while-held erotic) f (layer-while-held feet) ) (deflayermap (meta)) (deflayermap (erotic)) (deflayermap (feet))</code></pre> The meta layer is actually for the meta modifier. You might also know it as super, or the windows key. Erotic is the custom layer that has hotkeys for the browser: it makes j</kbd> and k</kbd> (e↓[jk]</kbd>) select the above/below tab, to do further actions on. Feet is the “navigation” layer, remapping h</kbd>, j</kbd>, k</kbd>, l</kbd> to the arrow keys (←</kbd>, ↓</kbd>, ↑</kbd>, →</kbd>). (deflayermap (default) w (multi lmet (layer-while-held meta)) e (layer-while-held erotic) f (layer-while-held feet) ) (deflayermap (meta)) (deflayermap (erotic) j (select-next-tab) k (select-prev-tab) ) (deflayermap (feet) h left j down k up l right )</code></pre> The meta layer itself doesn't need to have any mappings yet — we use it as just the meta modifier for now. But for that to work, we use multi</code> to also send the meta key down press, as long as we keep holding w</kbd>. ^{1 </a> } Erotic and feet don't refer to a real modifier though: they are custom layers, not inherently made to mean anything, and are given purpose by us. In erotic, I use select-next-tab</code> and select-prev-tab</code> as abstractions for however the fuck I actually do that; the real right side action is unimportant here, and would make things confusing for no benefit :p wonderful</a></h1> , now we can f↓[hjkl]</kbd> to get arrow keys, e↓[jk]</kbd> to select tabs in the browser, and w↓[???]</kbd> to use my compositor (window manager / DE / etc) actions. But I start running out of convenient to press hotkeys on just w↓</kbd> for my compositor; I now want to make wf↓</kbd> hold some of the more “complex” compositor actions. In niri (the compositor), I make hotkeys on meta+left</kbd>, meta+down</kbd>, meta+up</kbd>, meta+right</kbd>. The idea here is that when I combine the meta and feet layer, I should effectively get meta+arrow keys, so I can make mappings on those on the compositor side, and it'll work! But now, we are seemingly in both the layer meta and the layer feet. That's not exactly true! In kanata, only one layer is your “current” one. But, kanata remembers the previous layer that you were in. w↓</kbd> moves you into the meta layer. It is now your current one. You start holding f</kbd>; the meta layer doesn't have a mapping for f</kbd>, so the previous layer is looked up for a mapping. Our previous layer is “default”, which indeed has a mapping for f</kbd> — it moves us into the feet layer. Where now, this is our sequence of layers: default → meta → feet In our meta+arrow hotkeys, we rely on the meta layer to hold the meta modifier for us, and on the feet layer to translate h</kbd>, j</kbd>, k</kbd>, l</kbd> into arrow keys. This only works well because the meta layer doesn't have any mappings on h</kbd>, j</kbd>, k</kbd>, l</kbd>. Let's look at the behavior if it did have them. (deflayermap (meta) h (cmd fish -c "notify-send nuh-uh") j (cmd fish -c "notify-send nuh-uh") k (cmd fish -c "notify-send nuh-uh") l (cmd fish -c "notify-send nuh-uh") )</code></pre> Now when I w↓f↓[hjkl]</kbd>, I can do the more special compositor actions as expected. But if I do f↓w↓[hjkl]</kbd> (notice the different order), all I get is a nuh-uh! This shows that in kanata, the order matters. We are kinda in meta and feet at the same time, but each layer has its own precedence, and this changes depending on which we started holding down first. Of course I'm not going to have hotkeys specifically to “nuh-uh” me, so here there's conveniently no issue. It starts to actually come into play once you want this kind of composite layer with two, rather than one fake layer. Before, we relied on the meta modifier — the actual hotkeys were set in niri, not kanata. And so, only one fake / custom layer was actually in use — feet. Right now, we'll make hotkeys directly in kanata, expecting ef↓</kbd> — two custom layers together, erotic + feet. e↓[jk]</kbd> selects the next / previous tab. Let's make ef↓[jk]</kbd> extend that selection. </video> ...Where do we put those hotkeys at, though? Erotic doesn't hold some actual modifier for us, and neither do feet. To put our new hotkeys, we have to make a composite layer! (deflayermap (erotic-feet) j (extend-select-next-tab) k (extend-select-prev-tab) )</code></pre> You can actually name this layer whatever you want! I just choose to name it erotic-feet</code> because it makes it clear which other two layers it's combining. </blockquote> Currently though, we can never get to this layer. e↓f↓</kbd> results in default → erotic → feet f↓e↓</kbd> results in default → feet → erotic Once again, kanata is sequential, not combinatory, so we need to explicitly put ourselves into erotic feet somehow. For clarity: we are relying on the hotkeys set in the default layer, to move us into erotic or feet. Erotic doesn't have a mapping to enter feet — but the default layer does, and so it's used as a fallback. The opposite is also true: feet don't have a mapping to enter erotic — default layer does. But the default layer, naturally, doesn't move us into erotic feet. </blockquote> To do this, you'll supposed to put the “entering” hotkeys into both of the layers that you want to combine. (deflayermap (erotic) f (layer-while-held erotic-feet) j (select-next-tab) k (select-prev-tab) ) (deflayermap (feet) e (layer-while-held erotic-feet) h left j down k up l right )</code></pre> If we e↓</kbd> then f↓</kbd>, we get into erotic feet. If we f↓</kbd> then e↓</kbd>, we get into erotic feet also. It is crucial that we put the enterer in both layers — if we didn't have the e</kbd> hotkey in the feet layer, that would mean that e↓f↓</kbd> would work, but f↓e↓</kbd> wouldn't. What we are trying to express is “while I'm holding both keys”, rather than “if I start holding down these keys in this specific sequence”. So we need the enterer in both, to make sure it doesn't matter what order you start pressing e</kbd> and f</kbd> in. whoops no feet</a></h1> Remember the compositor meta+arrow keys remaps? We were relying on kanata's sequential layer fallback system, to actually get the arrow keys. w↓f↓</kbd> results in default → meta → feet; feet is the current layer, so of course we get our arrow key mappings. f↓w↓</kbd> results in default → feet → meta; the current layer, meta, doesn't have the arrow key mappings, but the previous layer (feet) does. So we fall back on it. Crucially, this only works because we have visited feet. But have a look at how we get to erotic feet. e↓f↓</kbd> results in default → erotic → erotic-feet f↓e↓</kbd> results in default → feet → erotic-feet With e↓f↓</kbd>, we never visit feet — we directly jump to erotic feet. With f↓e↓</kbd>, we never visit erotic — we directly jump to erotic feet. So if we ever happen to rely on the arrow keys hotkeys existing while in the erotic feet layer, it now again matters how we got there: f↓e↓</kbd> will work, but e↓f↓</kbd> will not. That's because f↓e↓</kbd> includes feet in its layer sequence, but e↓f↓</kbd> doesn't — so it can't rely on the fallback. Once again, we want the order to not matter. We might not need the arrow keys mappings in erotic feet specifically, but it's good practice to simplify things for the future you, and to always have all the children of a composite layer visited — that way, you build mental consistency you can always rely on. Yesterday, I realized that you can layer-while-held</code> multiple layers at the same time, which fixes the issue completely :D Let's look at our entire config again, now with the fixes. (deflayermap (default) w (multi lmet (layer-while-held meta)) e (layer-while-held erotic) f (layer-while-held feet) ) (deflayermap (meta)) (deflayermap (erotic) f (multi (layer-while-held feet) (layer-while-held erotic-feet)) j (select-next-tab) k (select-prev-tab) ) (deflayermap (feet) e (multi (layer-while-held erotic) (layer-while-held erotic-feet)) h left j down k up l right ) (deflayermap (erotic-feet) j (extend-select-next-tab) k (extend-select-prev-tab) )</code></pre> Switching to a composite layer now also holds for us the requisite layer that we expect to be held. f↓e↓</kbd>: default → feet → erotic → erotic-feet e↓f↓</kbd>: default → erotic → feet → erotic-feet Now if we relied on the arrow keys in erotic feet for whatever reason, that would work whether we got to erotic feet with e↓f↓</kbd> or f↓e↓</kbd>, because we visit the other layer “on the way”. Notably, the j</kbd>/k</kbd> to ↓/↑ remaps of feet won't work because our current layer (erotic feet) remaps them. Feet is the fallback, not the override. let's scale this</a></h1> Awesome! Now that it doesn't matter what order I press my modifiers, I want to expand this idea by making more hotkeys for the browser. You saw in the screen recording, that I currently can select tabs — after I do so, as a separate action, I can activate that tab. Would be nice to also be able to switch to the previous / next tab directly, without the activation step. And I want to be able to move my selected tabs, also. So in total, I want: e↓[jk]</kbd> to select a tab ef↓[jk]</kbd> to extend the current selection wef↓[jk]</kbd> to move selected tabs we↓[jk]</kbd> to switch to the previous / next tab ^{2 </a> . </video>} Here is our new config, with all the added enterers and combining layers that we need. (deflayermap (default) w (multi lmet (layer-while-held meta)) e (layer-while-held erotic) f (layer-while-held feet) ) (deflayermap (meta) e (multi (layer-while-held erotic) (layer-while-held erotic-meta)) f (multi (layer-while-held feet) (layer-while-held meta-feet)) ) (deflayermap (erotic) f (multi (layer-while-held feet) (layer-while-held erotic-feet)) w (multi lmet (layer-while-held meta) (layer-while-held erotic-meta)) j (select-next-tab) k (select-prev-tab) ) (deflayermap (feet) e (multi (layer-while-held erotic) (layer-while-held erotic-feet)) w (multi lmet (layer-while-held meta) (layer-while-held meta-feet)) h left j down k up l right ) (deflayermap (meta-feet) e (multi (layer-while-held erotic) (layer-while-held erotic-meta) (layer-while-held erotic-feet) (layer-while-held erotic-meta-feet)) ) (deflayermap (erotic-meta) f (multi (layer-while-held feet) (layer-while-held erotic-feet) (layer-while-held meta-feet) (layer-while-held erotic-meta-feet)) j (switch-next-tab) k (switch-prev-tab) ) (deflayermap (erotic-feet) w (multi lmet (layer-while-held meta) (layer-while-held meta-feet) (layer-while-held erotic-meta) (layer-while-held erotic-meta-feet)) j (extend-select-next-tab) k (extend-select-prev-tab) ) (deflayermap (erotic-meta-feet) j (move-tabs-next) k (move-tabs-prev) )</code></pre> You can see how this scales to be quite unreadable, lol :D The idea here, though, is that every layer has enough enterers for us to be able to get to the final erotic meta feet layer, regardless of the order. Also, we visit all the other layers that are logically pressed, on the way — so that we can reduce possible head pain in the future. This works! But with a caveat... A caveat that actually made me sure this blog post needs to exist. First, I need to select the initial tab, from which I'll then extend my selection: e↓[jk]</kbd>. After that, I start holding f</kbd> to extend: f↓[jk]</kbd>. I have selected the tabs that I want to move, so now I also start holding down w</kbd>: w↓[jk]</kbd>. Wonderful. I have moved my tabs. Now onto a separate action — I want to switch to the next tab: I release f</kbd>, and now only hold e</kbd> and w</kbd>: f↑[jk]</kbd>. Full syntax: e↓[jk]f↓[jk]w↓[jk]f↑[jk]</kbd> (try following along on your keyboard, to grasp the sequence a bit better) Selecting, extending, and moving works. But when I release f</kbd>, instead of me now switching tabs, I still move them! Why is that? It's another instance of how kanata's sequential layer system can end up being annoying. layer-while-held</code> means “on press, add this layer on top of the stack. on release, remove that layer from the stack”. We move through the layers in this sequence: default → erotic → erotic-feet → erotic-meta-feet (I'm omitting the “on the way” layers because they don't matter here, but they are indeed there). Erotic makes us a promise: “When you press f</kbd>, I will add erotic feet on top of the stack. When you release f</kbd>, I will remove erotic feet from the stack.” That promise (as far as I understand) is actually held. But a different promise takes priority. Because erotic feet tells us: “When you press w</kbd>, I will add erotic meta feet on top of the stack. When you release w</kbd>, I will remove erotic meta feet from the stack.” So when we release f</kbd>, erotic feet is removed from the stack as promised. But that doesn't do much because we are not in erotic feet anymore: we are in erotic meta feet. Since we are still holding w</kbd>, the promise of having erotic meta feet in the stack is still held up, by erotic feet. Our idea with erotic meta feet, is that all of w</kbd>, f</kbd>, e</kbd> need to be held at the same time. If one of them isn't currently being held, we need to leave the layer(s!) that require that key to be held. Kanata's idea is to keep the layer in the stack, as long as the specific key that entered it, is still being held. virtual keys</a></h1> Turns out, there's a solution! What we want, is to make releasing an enterer key leave not only the specific layer that it enters, but any (and all) layers that logically expect that key to be held. For this, we can put the on-release</code> action at the end of every enterer's multi</code>. on-release</code> is one of the actions that require us to pass a virtual key</a> — they are like aliases that can individually respond to a press / release, rather than being a compulsory press+release combo (as far as I understand them). So we will make a couple of virtual keys, that explicitly release all layers that necessarily include some sublayer. For the record, we do not care about the press / release functionality of virtual keys here, we are just required to use them because we need the on-release</code> action. (defvirtualkeys any-feet (multi (release-layer feet) (release-layer erotic-feet) (release-layer meta-feet) (release-layer erotic-meta-feet)) any-erotic (multi (release-layer erotic) (release-layer erotic-meta) (release-layer erotic-feet) (release-layer erotic-meta-feet)) any-meta (multi (release-layer meta) (release-layer meta-feet) (release-layer erotic-meta) (release-layer erotic-meta-feet)) )</code></pre> We can “call” (tap) one of these virtual keys, to explicitly release any (and all) layers that contain a given sublayer. Let's add the on-release</code> action to the enterers, in the rest of our configuration. (deflayermap (default) w (multi lmet (layer-while-held meta) (on-release tap-vkey any-meta)) e (multi (layer-while-held erotic) (on-release tap-vkey any-erotic)) f (multi (layer-while-held feet) (on-release tap-vkey any-feet)) ) (deflayermap (meta) e (multi (layer-while-held erotic) (layer-while-held erotic-meta) (on-release tap-vkey any-erotic)) f (multi (layer-while-held feet) (layer-while-held meta-feet) (on-release tap-vkey any-feet)) ) (deflayermap (erotic) f (multi (layer-while-held feet) (layer-while-held erotic-feet) (on-release tap-vkey any-feet)) w (multi lmet (layer-while-held meta) (layer-while-held erotic-meta) (on-release tap-vkey any-meta)) j (select-next-tab) k (select-prev-tab) ) (deflayermap (feet) e (multi (layer-while-held erotic) (layer-while-held erotic-feet) (on-release tap-vkey any-erotic)) w (multi lmet (layer-while-held meta) (layer-while-held meta-feet) (on-release tap-vkey any-meta)) h left j down k up l right ) (deflayermap (meta-feet) e (multi (layer-while-held erotic) (layer-while-held erotic-meta) (layer-while-held erotic-feet) (layer-while-held erotic-meta-feet) (on-release tap-vkey any-erotic)) ) (deflayermap (erotic-meta) f (multi (layer-while-held feet) (layer-while-held erotic-feet) (layer-while-held meta-feet) (layer-while-held erotic-meta-feet) (on-release tap-vkey any-feet)) j (switch-next-tab) k (switch-prev-tab) ) (deflayermap (erotic-feet) w (multi lmet (layer-while-held meta) (layer-while-held meta-feet) (layer-while-held erotic-meta) (layer-while-held erotic-meta-feet) (on-release tap-vkey any-meta)) j (extend-select-next-tab) k (extend-select-prev-tab) ) (deflayermap (erotic-meta-feet) j (move-tabs-next) k (move-tabs-prev) )</code></pre> Now, the release of an enterer key not only leaves the exact layer that it enters, but all layers that we may enter after the fact. Finally, with this laborious ass configuration, everything works exactly how we want! I select the initial tab, then extend selection, then move the selected tabs; I then release f</kbd> and FINALLY, I switch tab as I expect, rather than continuing to move. the power!</a></h1> The erotic layer, which is actually called “hack” in my configuration, has for a long time felt iffy to me: when I combined it with other layers to do more “complex” actions in my browser, some of the combinations were not understood by kanata, based on rules I wasn't sure existed. Now that I actually looked into it deeper, and solved it, it feels incredible to finally combine layers naturally, and not have to release all of them to switch to a different combination — I can just use these custom layers like I would be using normal modifiers. You might not yet have a need to make composite layers like this, but hopefully you now know how to. If in the future you get a cool idea for a layer that might need composite layers, you can go “this is gonna be a bit annoying but doable” rather than possibly give up on the idea because it “doesn't work”. footnotes</a></h1> ^{1 </a> We don't actually need the meta layer at all currently; omitting it entirely and making w</kbd> be just lmet</code> on the right side would suffice. But we're going to need this layer for later.} ^{2 </a> More specifically, this will skip over unloaded tabs.} smooth scrolling Axlefublr — Tue, 16 Sep 2025 00:00:00 +0000 I tried out Zen Browser recently, and one of the many good things about it that I noticed, is how smooth the scrolling feels. I thought: “surely it's not zen-specific!” and turns out that its smoothness is due to about:config</code> settings you can set in any firefox :D The biggest / most important change, that will make your scrolling a lot smoother, is setting general.smoothScroll.msdPhysics.enabled</code> to true</code>. Honestly, I'm not sure why it isn't true by default! (in non-zen firefoxi) But of course, I didn't stop there. Let's take a look at the other relevant settings. First of all, I'll point out that the other general.smoothScroll.*</code> settings, that aren't in the msdPhysics</code> section, no longer apply — so you can pretty much just ignore them. Unsure if that's intentional or a bug honestly; I remember seeing some issue that claimed this to be a bug 👀 Anyway! There are two quite core settings: mousewheel.default.delta_multiplier_x = 100 mousewheel.default.delta_multiplier_y = 100</code></pre> Pretty self-explanatory — these two multiply the horizontal / vertical scrolling speed. The baseline (but not necessarily the default) is 100 — you can come back to these later to more directly express “please faster” and “please slower”. I ended up sticking with 100 for both, however. general.smoothScroll.msdPhysics.motionBeginSpringConstant = 300 general.smoothScroll.msdPhysics.regularSpringConstant = 900 general.smoothScroll.msdPhysics.slowdownSpringConstant = 300</code></pre> “Spring” is an animation type. The constant here is somewhat of an arbitrary number, in not sure which range, but the main idea is that lower is more draggy / slow / smooth, and higher is more abrupt / fast / jumpy. By setting the begin and slowdown springs to a lower number, 300, both starting and ending a scroll feels very smooth and gentle, without being too slow. The regular constant, though, I have no clue does what! At least, I wasn't able to find a notable difference in my experimentation. But I set it to 900 for it to feel more “tight” general.smoothScroll.msdPhysics.slowdownMinDeltaMS = 12 general.smoothScroll.msdPhysics.slowdownMinDeltaRatio = 1.3</code></pre> These two I never quite got do what, either. general.smoothScroll.msdPhysics.continuousMotionMaxDeltaMS = 3</code></pre> This, as far as I understand, basically means “every how many milliseconds is the smooth scrolling logic calculated?” It's 12 by default, so 3 is a lot more smooth! At least by an eye test. </video> Here's how all these settings applied look like! Keep in mind, there might be some fps loss in the recording, so it likely looks even smoother irl. The blog post I was scrolling</a>. mouse mode</a></h1> I don't actually use my real mouse when scrolling, most of the time; I have two keys in my mouse mode</a> that send WheelUp</kbd> and WheelDown</kbd>, so that's how I scroll most of the time. Did a bit of an optimization on the side of my mouse mode, to make scrolling even smoother. o (mwheel-up 30 60) i (mwheel-down 30 60) w (mwheel-left 20 60) r (mwheel-right 20 60)</code></pre> The default “length” of a singular scroll (a nudge?) is 120 — it's noticeably more jumpy than the 60 I'm now using. To account for the loss of speed, I send the nudges more frequently: 30 instead of whatever value I used to have prior. This is what you're seeing me use in the recording, btw! Kanata does warn me, though, that setting the length to something else than a multiple of 120 is error-prone — some programs might get utterly confused. I already came across an example of that happening, with oculante</a>; but it wouldn't be the last issue oculante has anyway :p So I'll gladly optimize for the #1 place where I scroll — my browser 😌 acceleration</a></h1> There are another two settings that are interesting to play with. mousewheel.acceleration.factor = 2 mousewheel.acceleration.start = 20</code></pre> Start is “after how many nudges do we increase the scrolling speed?” and factor is “by how many times?” Using these two, you can make it so you start to scroll faster after some amount of continuous scrolling. Unfortunately factor has to be an integer :< so we can't speed up just slightly. I ended up going without this feature (setting start to -1</code>), but it might work for you 😼 i overuse anki Axlefublr — Sun, 31 Aug 2025 00:00:00 +0000 No, I have not burned out on anki. All the advice I share in my how to anki</a> blog post still works… A little too well, actually?? A very common issue anki users face is that your workload creeps up on you over time, constantly increasing and eventually burning you out. My system, however, is designed specifically to not allow that! What is “it only seems free!!” for others, is quite free for me. What this resulted in, is that I don't take notes at all. I either make an anki card, or discard the information. This has been working really well as I've already expressed, but has a more hidden caveat I noticed only recently. </hr> </a> I want to make myself an analog clock :3 Maybe a window, maybe an overlay widget; Some sort of easily and quickly openable gadget that would allow me to feel the time. Istg I've never been to the military, but I can only feel time on an analog clock; Digital ones tell me the time, but they don't show me it, yk? In my fairly short adventure of trying to find an analog clock thingymabop, I haven't found anything that I actually feel like using. TUI clocks are god awfully ugly and therefore impractical — too cell dependent to be graphically accurate and neat-looking. The browser is often a common platform to build guis in, and quite importantly easy to build guis in. I found a project</a> that is a basic analog clock website, then forked it</a> to make my changes. I quite like it! However the issue is that it is in my browser. Something I'd like to be able to do is look at the time, ad-hoc, while doing anything else at the time. If, say, I'm watching a youtube video in fullscreen, and then open the clock in a new tab, well now I've unfullscreened my video and it's a bit unpleasant :/ If I force open it in a new browser window, it's now slow to open! And that's no good... So I need some sort of “just a window” clock app / program, that opens fast and is still styled how I like it to be. I found this project</a> which might actually fulfill my needs, but I need to edit C++ code to customize it. Some very basic things are defined as uhhhhhh C header variables? (idk, don't ask me), but to make it be how I want it, I need to edit the normal source too. Somehow, in all my trying, I could not for the life of me figure out how to make the background of the app fully transparent. Funny thing is, the sides are already transparent, suggesting that it is something the program is able to do, but there's a square background defined god knows where, configured by god knows what! And I cannot change it 😭 At least, I don't know how... I was meaning to get back into trying to figure this out, after initially failing, but now I'm feeling like it's a bit of a fool's errand. How about I employ a fun learning trick I like to use? Instead of focusing only and exactly on my specific usecase, I'll use that problem as a motivator to go learn something larger. I want to make hotkeys that use niri --json</code> to do various windowing actions — cool, I'll learn nushell as it lets me operate on json conveniently, among many other things. Would be cool if floorp</a>'s wrapped tabs were all of equal size, rather than the last row expanding the tabs on it — epic, I'll learn css grid and only after realize that the idea was not feasible ^{1 </a> I want an analog clock — nice, I'll learn quickshell.} How exciting! New learning project :D I start reading quickshell's docs, and open the docs of QtQuick… Only to find myself in terror. There is so much! ^{2 </a> } So many pages, so many thingies, so much to learn. And all of this somooch (💋) will end up as anki cards, maintained in my memory forever, only for me possibly to never use like, 90% of it. There's a good chance I'll actually never get to making the clock, and leave after making a volume change osd. Yet, despite not being used information, I'll remember it until the end of time... THAT is when I finally noticed, that the volume of how I use anki, actually restricts me. Because of how strongly I rely on anki, it is the only source of information I'll often use. If I have something ankied, I will sometimes wait for the next review of some piece of knowledge, rather than just look it up again — doing so feels like a waste. A waste, because I'm effectively messing up the anki algorithm by doing another review that anki doesn't know about. Yes, having anki work correctly is apparently more important to my brain than the information I'm trying to remember in the first place 😮‍💨 Biggest example of this happening is alphabet indexes: I have them all as anki cards, and I expect anki to ensure I remember them all. This works quite well of course, but I have some letters the indexes of I'm not sure about. Pretty sure p is 16, u is 21, q is 17 and s is 19, but I wouldn't bet my life on it, you know? When manually sorting</a> something, I'll sometimes be in this strange state of unsureness, yet refuse to simply check. It wouldn't even take much time to do, either! But I'm stubborn on letting anki do its job. This phenomenon happens even with information that is still “new”, rather than thoroughly reviewed in anki. I rely on anki to solve what it hasn't even gotten to yet! Say I learn a new programming language. I make anki cards for everything that I learn while reading its book, and eventually finish reading it, “completing” my language learning. However, that's not exactly how it is in my head. Intead of the more natural flow of learn a bit + practice / use a bit, because of anki I've built up this strange expectation of “learn everything first, then use everything after”. My most recent big learning adventure was nushell, and it's exactly how it went — I was for the most part dead set on not using nushell until I've “finished” learning it, whatever the fuck that means. I believe this is due to anki once again (although autism plays a part too) — if I haven't gotten through some card, I don't know that information. Which is an awfully restrictive way to learn! Now, if I simply went through the new cards quickly, this wouldn't be much of a concern. But then I'd have a different issue! The massive workload 😔 So what I do instead, is have a queue of new cards that are went through slowly but surely. Quite often, to get to the new cards of the topic I'm currently learning, I'd effectively need to wait like 20 days, sometimes more. Learn something. Wait 20 days. Use it. I'm exagerating quite a bit, but putting it into words helps highlight just how silly my learning approach is. Due to the queueic nature of my learning, any small and big new learning adventures feel bigger than they need to be: “it's gonna be a while until I fully finish this” is what I subconciously think. God forbid I simply learn what I need in quickshell, and continue on with my life! Noooooo, I need to have all the niche details specifically memorized for some reason. Stupid. Learning feels big, because it's a bad idea to try to memorize information out of context. Intead of memorizing some big specific way of doing a task, understand and remember the parts that make it work — that'll make it a lot easier to reproduce on a whim. To make this work, I feel required to “consume” the entire documentation of some software to be able to use it all, often times. And then I carry the chain and balls of the eventual effort it takes to memorize that entire documentation. Some things really do not deserve it! And yet I can't know ahead of time what I'll be needing all the time, and what is a waste of energy to remember. The time and energy spent on remembering, is not spent on learning the next new thing, which results in a very “spiky” overall knowledge — I know some things very well, but almost refuse to know some things at all. If only there was some way to store information without metaphorically nailing it to the wall of my brain... Hmmm... duh</a></h1> It is that chain of thought that finally led me to create my noting system :D Yes, I literally did not have one before! I have magazines</a> of course, and they are INCREDIBLE, but they solve a different usecase than personal documentation-like notes. Trying to expand magazines to fulfill this new usecase I've acquired would be a misdesign. First, I create a directory named mdw</code>, according to my optimize paths</a> blog post. However, turns out I don't need to zoxide to there often at all! That's because I make a global hotkey that opens the directory in yazi. Now, usually I'd make it open in helix, but as I'll be converting most of more than 4000 anki cards, I'll probably be creating a bunch of note files! And doing so from helix is a bit of a pain... But quite nifty in yazi! The fzf</code> action in yazi is almost as good as I need it to be. In helix, the fuzzy file picker opens the file that you accept, but in yazi you are simply moved onto it. That's reasonable don't get me wrong, but having to press enter twice to open any file sounds hilariously laborious, so I soft-forked the fzf.yazi</code> plugin to automatically open the resulting file :3 This way, I'm just a single key (i</kbd>) away from fuzzy searching files I want to open, compared to the equivalent helix global hotkey variant. Except, I get a bunch more other actions I can do easily, and methods I can use to travel to some file or directory, which is very helpful. So helpful in fact, that mdw</code> having an optimized name is not actually that useful — I've zoxided into it maybe once or twice so far ^{3 </a> . I just do everything from the yazi that my global hotkey opens! But there are plenty of possible optimized names, so it's not that big of a deal to overoptimize 😌 After all, I really like how mdw</code> fits semantically as a name :3} Another pretty important piece of the puzzle is my fish autocommit</code> function — it automatically makes commits out of the files in the working tree, making helpful-enough messages. A bunch of my directories are automatically autocommit</code>ed daily, and mdw</code> is one of them! It's also autopushed, so I really don't have to worry about my notes not getting backed up. splitting</a></h1> My idea for mdw</code> is a “personal documentation-like directory”. That's most things! But I noticed that I have a few pieces of information that feel off to store in mdw</code>, despite it technically being the correct place. I have a hotkey for Enter the Gungeon that gives me a random active item; To do this, I store the list of all active items in a file. This isn't strictly cache or data-like — it feels more like “user information”; something I might actually wanna check manually as well. Because of this, putting it into ~/.local/share</code> or ~/.cache</code> feels a bit wrong. Another two files I have store important phone numbers, and chatgpt context prompts. Yeah, definitely off from mdw</code>. I create another directory named tiq</code>! The rough semantic for it is “would usually be a magazine, but would be a waste of a magazine”; Which is a much more understandable semantic for me than I initially expected it to be :D It now stores other neat things, like alphabet indexes, neat phrases like “thanks for being my voice”, my note to self about how I do my finances, what mods I play slay the spire with and how they should be configured. All things that would both be in the way in mdw</code>, and would also be harder to remember the existence of. It is the “optimize paths” idea that makes this directory's existence viable, in a sense. By using arbitrary-ish names, that don't inherently mean something, I can assign a feel meaning to them. How would I name the two directories naturally? “documentation” and “information”? I guess that's not too bad... But still! I'd think 7 more times before creating the second one, if I couldn't put it unsuccinctly. got hands</a></h1> This whole adventure got started by me beginning to learn quickshell, but it's going to be quite a bit more time until I continue. My goal now is to process all of my anki cards; to go through all of them, and decide on a case by case basis what should simply be a note and what should also (note the also) be an anki card. 4000 cards is no joke! Not something I could conceivably convert in a day, so it's taking me quite some time. As a motivator, I decided to write down my progress as I do it, so that eventually I could figure out how many days it'll take me to finish. Here's the data so far: 25.08.12 0 of 4000 (not a data point) 25.08.15 160 of 3928 = 4.0% 25.08.15 173 of 3920 = 4.4% 25.08.15 352 of 3920 = 8.9% 25.08.15 692 of 3883 = 17.8% 25.08.16 702 of 3844 = 18.3% 25.08.18 703 of 3797 = 18.5% 25.08.19 755 of 3759 = 20.1% 25.08.21 763 of 3716 = 20.5% 25.08.21 780 of 3688 = 21.1% 25.08.21 874 of 3644 = 24.0% 25.08.22 899 of 3619 = 24.8% 25.08.25 1089 of 3595 = 30.3% 25.08.25 1099 of 3555 = 30.9%</code></pre> It's taken me roughly 2 weeks to process roughly a third of all my cards. You might naturally assume that to finish processing them, it'll take me roughly another month. But that's not the full picture! Take a look at the quite big jumps: from 8.9 to 17.8, 21.1 to 24.0, 24.8 to 30.3 That is me processing cards that I either don't intend to note, or are really easy to note in bulk. More precisely, those are cards for country flags, country locations on a map, alphabet indexes, decimal and hex indexes of ascii characters, hiragana, katakana, and morse code. So my data is a bit skewed in a positive direction, for me to be able to draw the “around a month more” conclusion; It's likely going to take more than a month, but how much exactly I'm not sure 🤷‍♀️ semantics</a></h1> As I process cards, over time I'm feeling out what my semantics are, for what is a note and what is a card. At first, fueled by the strength of my new belief, I was quite delety — “I overuse anki, and should heavily lean towards notes” is the idea that I'm running with. But over time I'm figuring out the grey area a bit more complexly. Some things are hard to note, because how do I name their section conveniently? weird behavior of programming language #72</code> will get tiring quickly, so I come up with heading titles on a best effort basis. This puts into perspective the power of anki for the usecase of knowledge you don't know you don't know. There are quite many things that are surprising, and hence things that you won't think to search for, in your notes. Using anki to retain at least the knowledge of the weirdosity of the behavior is quite effective, because of that! And then your notes can expand on the itty bitty details. Despite that though, quite a lot of this type I still convert fully into notes, deleting the original anki cards. I care about knowing about niche but significant behaviors for things I actively use, but that's not all the knowledge I store: I have quite a few cards for python, but I don't use the language much, and want to use less of it :p So basically every python card gets converted into a note, no matter how awkwardly I have to word it. And that's kind of the nice thing about it: instead of having to decide to completely discard my python knowledge, I can simply sweep it under the rug by putting it all into a note. If I ever need to refresh my snake skills, I know where to go — my note for python! I'll then go through the entire file, going “oh huh! good to know” until I'm ready to use the language again. Or, you know, just search within the note for things that are relevant :p There are quite a few other things, that truthfully I should have never carded in the first place. Systemd-related information is unfathomably difficult to memorize. All the various properties you have access to, are named incredibly inconsistently, so as soon as you start to develop a helpful memory semantic, another property completely breaks it. Is it “delay” or “interval”? You never know 😌 Programs that I use in some limited capacity, and probably will never use the full power of, simply due to lack of need. The two examples that come to my head immediately are zola</code></a> (the SSG I use for this website) and just</code></a> (project-specific command executor) There's quite a few niche and hyperspecific details I memorize about both, that I have literally never used and likely won't. But as usual, just straight up losing that knowledge would feel bad :c Really really excited to convert this genre of cards into notes, to never have to plague my mind with maintaining it in my memory. Then there's the really wack kind — programs I literally never even used, but learned. git-who</code></a> is one of them. A really nifty program for viewing history of contributions over time, getting a better overview about who contributed where at which periods of time. Pretty awesome! However, I don't think I have ever used git blame :p So you can probably see how I wouldn't have yet used git-who</code> either — yet the anki cards remain. Simply hilarious! </hr> </a> I can't wait until I finish converting all of this and that into notes, and can get back into learning new things. Now, unbounded by anki, I'll be able to learn in a much different way than before. Yesterday, I got a taste of this new way of learning, and it is RAVENOUS /pos I have a couple of interactive ffmpeg functions I wrote for myself in fish shell: I get asked a series of questions and that results in some specific ffmpeg command to be executed. The logic is of course written by me, but the ffmpeg flags I figured out with ai. Now, it all works, but I'm well aware that I shouldn't trust an ai to give me the best / most optimized output; Learning ffmpeg would be insurmountable with my previous anki workflow, but now that I don't need to have 100% correct knowledge, I can far more reasonably just “look around” the ffmpeg manpages, the internet, and more naturally collect information, not requiring myself to learn from the absolute base. It was so fun! Like, holy shit! I always assumed learning ffmpeg in any capacity would be basically impossible, but no, not really! As I looked through the flags my functions were using, I discovered and learned about them bit by bit. Intead of a third of my energy being spent worrying about how to anki the details succinctly, I was free to roam in the flowers, exploring the sea of ffmpeg options, and to be enthralled by the process. No longer was that learning that I had to “get through” — no, the journey itself became much more enjoyable, because the expectations are much more reasonable. I now have a nice note about ffmpeg, where all I know so far is collected, no matter how wrong or inprecise; as now, more naturally, it's something that can be developed over time, not set in stone while I'm not even certain about the material. It is heavenly! a quote</a></h1> I announced writing this blog post on my discord server</a>, and got this absolute peak response: “Is the blog post one full document, or is it broken up into anki cards that cover each individual aspect?” Really puts into words, how silly my obsession of “anki only, no notes” was. Now all that's left, is to not develop the opposite one, where I refuse anki for very good-to-anki things :p footnotes</a></h1> ^{1 </a> I'm not mad about this btw — the main goal was to learn css grid, but hide the effort from my psyche with the promise of something really cool. I didn't get that something cool, sure, but by the time I finish learning, the urgency of the motivator has already died down — it was used as coal for the fire of learning 🔥} ^{2 </a> Actually I ended up deciding to learn eww</code> instead, because the quickshell package has a package conflict that hasn't been solved in more than a week now. But I'm checking every once and again if it's fixed, and might end up learning quickshell still. Quite}tea with honey without honey no tea</a> of me :3 ^{3 </a> It's been 10 days since I started converting cards and using mdw</code>} blammo Axlefublr — Wed, 30 Jul 2025 00:00:00 +0000 I use the yazi</a> file manager, and like it a lot! Most of my file operations, including even cd</code>ing sometimes, is done directly from yazi. Which is why I add a couple of powerful special hotkeys to it! For example, I quite often need to cut videos; Unlike a normal person, I refuse to use an actual editing app, and instead I do it with ffmpeg</code>. I wrote some interactive ffmpeg fish functions</a>, and integrated them into yazi: On a press of a hotkey, all the files that I selected in yazi get passed to the function, and iterated on one by one. I then answer “questions” to edit the videos however I wish. This is really neat, but not super scaleable in a sense: I can't make a hotkey for every ad-hoc action, can I? It makes sense to have shortcuts to the really common actions, but you won't know if an action is common or not until you've already done it quite a few times. If you're too quick, you might end up with a “dead” hotkey in your configuration, But if you don't provide yourself any shortcut, doing The™ Action™ might be really laborious. ^{1 </a> } I came up with an idea that lets me seamlessly connect yazi's selected files to my shell, and I find the design really cool and nushell-like :D fishangling</a></h1> Let's start with how I reached the idea in the first place; why it even needed to exist. Yazi allows you to make mappings that call shell commands. In those, you have access to $@</code>, which means “absolute filespaths to all the currently selected files”. To handle spaces, you seem to need to specifically enclose the $@</code> in doublequotes. 'shell --confirm -- ouch decompress "$@"'</code></pre> The --</code> argument allows us to not have to quote the command itself — everything after --</code> is considered a raw part of the actual command. This works, as you'd expect! I can select multiple archives and decompress them all with a hotkey ^{2 </a> . But it's rare for me to just call commands directly; Often times, I write some sort of functionality in a fish shell function, and invoke it with fish -c</code>. All my various ffmpeg functions are written in fish, for example:} ''' shell --block --confirm -- fish -c 'ffmpeg_convert_to_mp3 "$@"' '''</code></pre> Except... this doesn't work. "$@"</code>, that just expanded absolutely correctly, no longer does inside of an argument to fish -c</code>. You see, I immediately assumed that the $@</code> syntax in yazi is its own thing, rather than the usual POSIX $@</code>; Fish shell actually uses $argv</code> to mean the same thing, so I guess I can simply use that, neat :D ''' shell --block --confirm -- fish -c 'ffmpeg_convert_to_mp3 "$argv"' '''</code></pre> Except...... It also doesn't work. So $@</code> is a yazi-specific thing, and perhaps it only expands correctly when provided as a separate argument, on its own, rather than part of a bigger argument 🧐 I'm being pretty vague here, with “doesn't work”, but that's because the semantics I still don't fully understand, and my experiences with them are very blurry. I feel that sometimes, it expanded all the paths into a single string, rather than multiple arguments, other times, didn't expand anything at all, maybe it didn't handle spaces correctly? Regardless, I decided to create my own solution for providing the list of arguments into fish from yazi, that worked by far more clear and guessable rules. Welcome to “blammo”! Yeah, I really didn't think much about the name of this thing, and it just kinda stayed “blammo” forever 😭 If you've been reading my blog posts for some time, you might've noticed how much I love this word, lol. Fun fact, my insane overuse of it comes directly after this video</a>! blammation</a></h1> I wrote this simple yazi plugin: --- @sync entry return { entry = function() local collector = '' for _, url in pairs(cx.active.selected) do collector = collector .. tostring(url) .. '\n' end if #collector == 0 then collector = tostring(cx.active.current.hovered.url) .. '\n' end local file = io.open('/home/axlefublr/.cache/mine/blammo', 'w') if file then file:write(collector) file:close() end end, }</code></pre> Yazi is in very active development, for more better than for the worse; So don't expect this to straight up work if you're reading this post in the future. The main idea, though, is pretty simple: We take the full paths of all files we have selected, and convert them into a string which has one path per line. If we don't have any selected, we simply take the filepath that our cursor is currently on. And we write that to some file. The path doesn't matter, but I like to use ~/.cache/mine</code> to hold various cache-like files that I don't want removed on reboots, which would happen if I put it in /tmp</code>. I have the opposite idea also, where I hold files I do want eventually auto-cleared in /tmp/mine</code>. Anyway, after you put the above code into ~/.config/yazi/plugins/blammo.yazi/main.lua</code>, you can now access it in your yazi mappings with plugin blammo</code>. When you call the plugin, it stamps the current selected files into a file, which you can immediately read as a list of arguments. In shells, you can cat some-file</code>, and it will convert each line in a separate argument. Which is very clean, simple, safe, and nifty! We can now fix the previous ffmpeg mapping I was trying to create: [ 'plugin blammo', 'shell --block --confirm -- fish -c "ffmpeg_convert_video (cat ~/.cache/mine/blammo)"' ]</code></pre> And this does work 🥳 Having to type out the blammo filepath for every hotkey is a bit laborious, though, so I made myself a nifty little fish alias: function blammo cat ~/.cache/mine/blammo end</code></pre> So now, the yazi mapping is: [ 'plugin blammo', 'shell --block --confirm -- fish -c "ffmpeg_convert_video (blammo)"' ]</code></pre> This solves the issue I had at the time, but highlights something interesting: I was just able to, effectively, reach into the context of yazi, from outside of yazi 🤔 As long as it's properly updated, nothing is stopping me from using (blammo)</code> just interactively in my shell! I made my quit and suspend</a> hotkeys blammo</code> first, so that leaving yazi ensures the blammations are up to date. { on = ':', run = [ 'plugin blammo', 'quit' ], desc = 'Exit the process' }, { on = '<C-z>', run = [ 'plugin blammo', 'suspend' ], desc = 'Suspend the process' },</code></pre> Now I can select some files in yazi, suspend with ctrl+z</kbd>, and execute some arbitrary shell command on the files I had selected! I recently had a usecase, where I wanted to convert a video into webp (which you can apparently do): magick (blammo) (blammo | path change-extension webp)</code></pre> I love it!! But it's a biiiiit wordy — typing out (blammo)</code> is more syntax than I'd like 🤔 So I came up with a funny but reasonably solid hack! At the end of my fish_prompt</code> function, I put the following line: set -g in (blammo 2>/dev/null)</code></pre> fish_prompt</code> is the function that runs every time your prompt needs to be drawn. Meaning, before every command. So, we put yazi's latest selected files into a global variable in</code>, that we can then use directly as the list of filepaths! magick $in (path change-extension webp $in)</code></pre> And if we do indeed select multiple files, you could blammo a loop: for the in $in magick $the (path change-extension webp $the) end</code></pre> Semantically, this is quite a bit better :D In nushell, $in</code> means “whatever was piped into the current thing”, so here it's as if we're piping the list of filenames into fish, quite neat! p.s.</a></h1> Ahhhh... no better way to get the correct solution than to post the wrong one on the internet 😌 ^{3 </a> The yazi author read this blog post, and shared the more proper way of doing what (blammo)</code> was initially made for!} ''' shell --block -- fish -c 'ffmpeg_convert_to_mp3 "$argv"' "$@" '''</code></pre> First of all, you can now omit the --confirm</code> flag. But more importantly, you can probably intuit the semantics of yazi's "$@"</code> now. It is only resolved as a top level argument to the overall command; it's not a find and replace across all text of all arguments. So here, we specify the fish program in the string after -c</code>. The program makes use of the arguments provided to it. After the stringed fish program, we pass arguments to it with "$@"</code>. With this knowledge, you can now avoid needing blammo to pass selected files to predefined mappings, and can use this concept to pass arguments into other interpreted programming languages, like nushell probably. But the main idea of blammo, and why I wrote this in the first place — connecting yazi's selected files into your shell — is still alive and useful, even with this new discovery! :D footnotes</a></h1> ^{1 </a> Sounds similar to the types of situations that}harp</a> solves, doesn't it? You're correct! Harp could be implemented into yazi to provide a pretty nice productivity boost, but so far I don't find myself executing enough commands from the context of yazi to really need harp. ^{2 </a> I'm aware of the built in yazi unarchiver, but it's been super wonky for me. I'd much rather use the behavior I'm more familiar with, using ouch</code>. This hotkey still exists, but I actually made “opening” archives automatically use ouch decompress</code>. How did I do that? Exercise for the reader 😌} ^{3 </a> To be fair, I never asked anywhere for how to solve the issue of passing arguments to fish, neither have I searched. I have a tendency to solve my problems my own way before considering grabbing some pre-existing solution :>} proxy things Axlefublr — Sun, 27 Jul 2025 00:00:00 +0000 I'm unfortunately in russia. Since the start of the war, most services have left the country, now requiring a vpn to use. But funny thing — so did the vpns! First, some now required a vpn to access them (the another vpn). Sounds pretty useless, but I could conceivably use some bad free vpn to then enable the good one, disconnect the free one and continue using the good one until I reboot. So that worked to an extent, but it didn't last that long. One by one, vpns started massively throttling, taking tens of minutes to connect, and eventually just not connecting at all. Express, Nord, Air, Surfshark, CyberGhost, Private Internet Access, Proton, Windscribe, Mullvad — are all vpns I've used or tried using, until ultimately they all broke. I'm in quite a salted vegetable here, I certainly need to access things like discord, youtube, spotify, and most of the internet honestly; what do I do? the name of this heading would be a spoiler to the dramatic tension of the previous sentence</a></h1> VPNs are not the first technology that allows you to avoid geo-restrictions. Thanks to my friend's effortful history lesson on networking, I got a better idea of what a proxy is. Better enough to now consider it as a possible solution. A proxy, in my understanding, is a server that can make requests for you. It's exactly like sexism actually: ^{1 </a> you, the russian woman, saying something to another server is rejected. So you ask a man (the proxy) to say the same thing for you, and give you the response — now it suddenly works.} VPNs often work globally on your system which is very convenient, but you do tend to need geo-restriction-unlocking for only a few places. Those few places, usually, allow you to configure the proxy! There are HTTP proxies you can find out there for free, but really shouldn't: the S part of HTTPS is very important for the security of your data, as without TLS, the data you send will be visible to the proxy itself — a bank password that you enter, for example. Finding free HTTPS proxies is then a privacy concern, so I decided to buy one instead. for the russians</a></h1> In this section I'll go over my exact process for buying a proxy, but if you're not russian you're better off using some store that's not specifically tailored to russians. Google for “buy https proxy” and you'll probably get there. Although, I'd recommend actually going through with my suggestions in the blog post, after you've completed it — I will be omitting some things until later notice for dramatic effect. As a hilarious way to force non-russian readers to skip this section, I'll write it in russian. Нашла сайт, где можно купить прокси: https://proxys.io/en</a> Когда юзала VPNы, самые лучшие результаты у меня были используя сервера в Нидердландах, поэтому решила купить и прокси там же. Я плачу криптой, если честно уже не помню почему; Для этого я использую сервис MATBEA</a>. У них ещё есть приложение на андроид, оно мне кажется более приветливым, так что обычно использую его. С помощью MATBEA, можно обменяться валютой с человеком — вы отправляете классические деньги со своего банка (тинькофф например ^{2 </a> ), они подтверждают что пришло, и крипта, которую MATBEA держит во время операции} ^{3 </a> приходит к вам на аккаунт.} Но на протяжении этой операции, есть несколько коммиссий из-за которых сложно предугадать сколько денег в итоге попадёт на счёт proxys.io. Так что моя личная стратегия, ложить на 30% больше денег на счёт матби, чем я собираюсь в итоге получить на счёт proxys.io. Не волнуйтесь, реальная коммиссия не буквально 30%, это больше для безопасности, чтобы потом в жопу не ебаться когда вдруг не хватает 0.003 биткоина. Как моя подруга сказала на этот счёт: “лучше перебдеть чем недобдеть”. И так, план следующий: Выберите https прокси которую хотите купить</li> Оплата через крипту</li> Вам выставится адрес, на который нужно отправить какое-то количество скорее всего биткоина</li> Идите на матби</li> Переводите чуть побольше чем надо на матби аккаунт с помощью “Пополнить”</li> Сделайте “Обмен” на валюту, которую proxys.io от вас хочет</li> Жмите “Отправить”, на адрес получателя</li> Восемь раз отмерьте (проверьте что правильно скопировали и вставили адрес, или просканиуйте qr-код)</li> Один раз отрежьте (отправляйте, но поставьте низкий приоритет чтобы не было ебейших комиссий)</li> Ждите миллиард лет, пока деньги дойдут до proxys.io. У меня это обычно занимает где-то час</li> </ol> Готово! Теперь у вас есть прокси 🥳 Юпииииии Блять ненавижу писать по-русски, это намного сложнее чем по английски 😭 Но “бит” смешной так что надо было 😤 по сусекам</a></h1> I have an https proxy now! :D And I paid just 2.67$ (monthly) for it! VPN prices generally start at 5$, so that's a pretty damn stellar deal, considering how effective the proxy later became for me. So even if you aren't in my situation, and VPNs do work for you, using a proxy might still be more cost-effective, if nothing else! </hr> </a> The proxy comes with a set of “information” that you're going to use to plug it into places. Let's name all of them, so that they're a bit more familiar! ^{4 </a> } thingy</th> namey</th></tr></thead> 162.3.164.178</td> ip address / hostname</td></tr> 8676</td> port</td></tr> user223767</td> username</td></tr> eIwB7xB</td> password</td></tr> </tbody></table> The ip address + port are probably discoverable enough ^{5 </a> where someone unwanted could get access to your proxy, so it will usually come with a username and password as well. You are meant to keep these secret 😼} A lot of places that let you configure a proxy, simply have separate fields for each of the 4 values. But some don't! The following syntax is something you might see yourself using in those other places: user223767:eIwB7xB@162.3.164.178:8676</code></pre> i.e. username:password@ip:port</code></pre> It's rare to use them bare like this though, usually you're expected to give a link: https://user223767:eIwB7xB@162.3.164.178:8676 https://username:password@ip:port</code></pre>it works... sorta</a></h1> The main, and almost only place where I need georestriction unlocking, is my browser. Through some steps (that I'll teach you later), I was successfully able to use my new proxy, and no longer needed to jump through 5 free vpns :D It seemed surprisingly straightforward, and continued working for a while, until I switched to floorp</a>. In firefox, everything worked just how you'd expect. But on floorp, suddenly, youtube videos were not playing 🤔 Note, the entire rest of the website was working, just not actual playback. At the time, this put me into anxiety mode; I was considoring ^{6 </a> using firefox specifically for youtube, but that sounded like quite a shitty tradeoff. Firefox and floorp handle proxies differently somehow. I wasn't quite sure why yet.} My favorite puppy ^{7 </a> helped me solve this, with some bespoke setup that involved its VPS' socks4 proxy. Still not exactly sure what all this is, but now I'm hearing this 🧦 term when it comes to proxies. Interesting.} And so, I was paying for my own proxy to use for most things, and using my partner's socks4 proxy for youtube. Feels kinda bleghy, right? Shouldn't my own proxy already accomplish everything? I realized my grave underunderstanding recently, while trying to set up discord. Web discord is just fine for me, but it's crucially missing the ctrl+123456789 hotkeys, so I really wanted to try out vesktop to get those. Both fortunately and unfortunately, there the proxy setup was more difficult to figure out. As I was trying different things, I came across a new nugget of knowlege: “https proxies are solid for TCP, but fucky for UDP. socks5 solves this though” Through my friend's networking history lesson, I got a slightly better idea of what TCP and UDP are usually used for. And UDP, crucially, is used for video playback, among other things! Huh! The exact thing that's not working off of my proxy in floorp. Hmmm… So if I had a socks5 proxy, this might get solved? I was playing around in my proxys.io (where I bought my proxy) account, and happened to enter into the proxy's information page again. I discovered a new field, that I never understood or paid attention to before: “socks5 port”. Well holy shit! Does this mean that my proxy is a socks5 proxy too, rather than only https? I reconfigure the proxy in my browser to use socks5 instead of https, and provide the new port. I restart my browser and rush into youtube, to be completely dumbfounded by seeing that it works. Hoooooooly fucking shit I was paying for this proxy for more than half a year at this point, and all I fucking needed to do was realize that socks5 is a level up from https, rather than being some fancy other genre, and that it's simply something I should be using everywhere I can, to make more things work more easily. ok ok let's use this proxy, let's use this proxy in our apps</a></h1> (/ref</a>) Socks5 is the new nugget of information, because of which I wanted you to read more before acting; When buying a proxy, make sure it's both an https and a socks5 proxy — that makes it much more powerful and appliable in more scenarios. Let's start with the most common one! firefox</a></h2> The firefox / floorp / zen / etc setup is pretty simple. It should be as simple in chromium-based browsers, for the record, but you'll have to find that out yourself :p Install the FoxyProxy extension</a>. Grant it the permissions it's asking for, and allow it to run in private windows. Go to the extension's settings → Proxies. Here we're going to add our proxy as a socks5 one. Press the “Add” button, and fill in the hostname, port (specifically the socks5 one, not the https one!), username, password. Set “Type” to SOCKS5. I have “Proxy DNS” enabled, but I'm not sure if we need to honestly. Now, add these patterns: cludation</th> pattern</th></tr></thead> include</td> *</td></tr> exclude</td> *localhost*</td></tr> exclude</td> *127.0.0.1*</td></tr> </tbody></table> As you use the proxy, you may find places that you specifically don't want to proxy, and will be able to exclude them here. Crucially, though, we begin by excluding localhost — you don't want to proxy your own computer's local network. You can also handle this the other way around: by not proxying anything by default, and adding stuff to proxy as you go. But if you're a russian reading this blog post, you probably want to proxy everything by default, due to how much stuff is blocked in russia nowadays. If you're in China, similar idea probably applies. Now, press “Save” and enable the proxy by clicking on the extension button, and pressing “Proxy by patterns” — That variant uses the patterns that we just provided above. After a browser restart for good measure (shouldn't be needed usually), your proxy should be working! 🥳 android</a></h2> It is the socks5 revelation that let me use my proxy on my phone too, while in the past I could only use it helpfully on my pc. We're going to use an app called “Drony”. It's not on play store, so simply google “drony apk” and pick your favorite sketchy website to download it from. In the app, swipe right to get to settings, go to “not wi-fi (mobile, ethernet, …)”. Fill in the hostname, port, username, password; set “Proxy type” to “SOCKS5”. Go back, and now press on “Wi-fi”. If you don't have any networks listed, you're probably chill already. Otherwise, pick the first one probably, and fill in the details exactly like above, again. Go back twice and swipe left back to the log tab, and press the “Off” button so that it's “On”. The proxy should now be working, globally, on your phone 🥳 After figuring this out, I have effectively doubled the value I get from my proxy for the price that I pay for it. 2.67$ for my pc and phone? Insane! I was really excited about how straightforward this solution is, and wanted to help out some russian that I know. Found a friend that was also doing the 5 vpns strat, and made them go through the setup process, using my proxy's information. It worked perfectly! Kinda strange, isn't it? Usually, setting up something one someone else's device is bound to not work in many strange ways, but this time everything just worked perfectly with no finagling. So it seems like it's reproducible! :D “Works on my machine”? Nah! “Works on your machine”. etc</a></h2> Now onto the more interesting to explain genre of proxiable things: “other”. I'm assuming you're on linux, btw. There are these three interesting environment variables: http_proxy</code>, https_proxy</code>, all_proxy</code>. One / some / all of them are understood by various apps, including but not limited to cli programs, to configure their proxy. Interestingly, they are indeed specified as lowercase, rather than uppercase, which is quite unusual for environment variables. In my usage, I could never just stick to providing one of them, and for them to work, so the safest best is to provide all three. All of them use the https://username:password@ip:port</code> syntax, so to launch some app with your proxy, you'd do something like: http_proxy=https://username:password@ip:port https_proxy=https://username:password@ip:port all_proxy=https://username:password@ip:port some-app</code></pre> I'm not 100% sure, but like 80% sure that you still can provide https to the http_proxy variable, despite it seemingly expecting the proxy without TLS. Both http_proxy</code> and https_proxy</code> expect the http version of your proxy, rather than socks5; all_proxy</code> doesn't have such a restriction, so you can provide the socks5 version of your proxy with socks5://username:password@ip:port</code>. But both of that, I believe, is a “usually” — http_proxy</code> and https_proxy</code> might allow socks5 in some apps, and sometimes all_proxy</code> will not understand socks5. All this “knowledge” is collected by me via experience and reading random stuff, so I'm very much farming corrections here :D Dm me on discord @Axlefublr or email me</a> if I'm wrong on some things directly above, I'd love to learn! The 3 variables you can quite easily expect to work in various networking-related cli programs, like curl</code>. But otherwise, their usefulness can be quite varied. If a given program allows you to pass the proxy to it directly, via a flag or a config option or some such, that is much more likely to work. But the three proxyteers</del> variables can potentially save your ass if you don't seem to have a more “proper” way to provide a proxy, yet they (the vars) surprisingly work. Now let's talk about proxying something that doesn't care about the proxyteers. electron</a></h2> Discord is an Electron app; I believe Electron doesn't come pre-built with (https?|all)_proxy</code> support, so whether you can use the variables depends on the specific app. Well, for discord it doesn't work at least, neither does it for vesktop. However! I found a cool electron flag: --proxy-server</code>. This should be supported in any electron app, as I assume electron takes care of the networking things, including the proxy. It has an interesting limitation that we haven't yet considered, though: Use a specified proxy server, which overrides the system setting. This switch only affects requests with HTTP protocol, including HTTPS and WebSocket requests. It is also noteworthy that not all proxy servers support HTTPS and WebSocket requests. The proxy URL does not support username and password authentication per Chromium issue. </blockquote> Our proxy requires a username and password, so we can't pass it directly into the flag, how we usually can. Electron not understanding username + password proxies might actually be the reason why (https?|all)_proxy</code> don't work — maybe they actually do, just not when username and password are required. To work around this, we need to somehow convert our proxy to a non-passworded one, so that we could just provide the hostname:port. privoxy</a></h3> ↑ is the program that will allow us to do that! Really frequently, various programs that allow you to do fancy things with proxies are really fucking complicated to make work. How often have you heard “just use wireguard”? And yet I find it extremely overwhelming... So I was both quite surprised and happy that privoxy isn't like that, and its setup was incredibly simple :D First of all, install it of course. On arch, it's just privoxy</code> in the repos. On not arch, I hope it's also just as easily installable :3 The default config file is in /etc/privoxy/config</code>. Add the following at the absolute end of it: forward-socks5 / username:password@address:port .</code></pre> With your actual username, password, ip address, and 🧦🧦🧦🧦🧦 port, of course. That's the entire config!! It's literally that shrimple :> You can now enable the systemd service that should come with your installation, with: sudo systemctl enable --now privoxy</code></pre> It will both start the privoxy service right now, and on subsequent logins. If you don't have the systemd service for one reason or another, just run it yourself with privoxy /etc/privoxy/config</code> — it daemonizes by default anyway. Right! I forgot to explain what it even does hehehehe Basically, we're starting a uhhhhh thingy on our local network, into which we can send requests. I think it's not a lie to just call it a proxy? Yeah we're starting a proxy locally I think! So this local proxy can accept requests, and relays them to our main, actual (and passworded) proxy. Meaning that we get to specify an address + port without needing to specify the username + password 🥳 The “information” of privoxy is 127.0.0.1</code> for the ip address, and 8118</code> for the port, by default. You can check if it's actually working with this command: curl --proxy http://127.0.0.1:8118 https://httpbin.org/ip</code></pre> It should 1. not infinitely hold and 2. show you information about your actual proxy ! Coming back to the discord situation, I was eventually able to run it with: discord --proxy-server=127.0.0.1:8118</code></pre> Which is so awesome! I'm surprised I was able to figure out so much in one day and actually make discord work, rather than giving up. The power of proxies seems to scale indefinitely, directly proportional to your networking skills; Slowly but surely, I seem to gain those, due to the consequences of this stupid ass war. Although I sure wish I didn't have to do this out of requirement! lol final battle</a></h1> Now using the discord app, I start to type out some message sharing my excitement; But I get stopped when trying to use yet another “fancy quote” or 🤯 or ←↓↑→ — the horror! Discord doesn't support wtype</code>... I have a lot</a> of direct hotkeys to various symbols and emojis, and all of them use wtype</code> to be entered. This is a really big deal to me, much more than ctrl+number hotkeys :( A pretty obvious first idea is “it's probably some wayland thing” — discord is probably running in xwayland mode unecessarily, so wtype not working is not surprising. But funny thing is, discord doesn't have a wayland version anyway! How the fuck did this happen lmao! So I try to handle this by using vesktop instead 🧐 There, forcing wayland is actually a thing you can do, but no dice on the wtype issue anyway :c Since there is no one singular way to force wayland for apps, I decided to just keep throwing shit at the wall until it worked. I started with the basic variables and flags, but at the end I ended up with this monstrosity: MOZ_ENABLE_WAYLAND=1 NATIVE_WAYLAND=1 ELECTRON_OZONE_PLATFORM_HINT=auto \ GDK_BACKEND=wayland QT_QPA_PLATFORM=wayland SDL_VIDEODRIVER=wayland \ vesktop --proxy-server=127.0.0.1:8118 --ozone-platform-hint=wayland \ --ozone-platform=wayland --enable-features=WaylandWindowDecorations \ --enable-features=WebRTCPipeWireCapturer --enable-features=UseOzonePlatform --gtk-version=4</code></pre> The shit, to everyone's great surprise, did not work. How curious. Actually, after I forced wayland (even the normal-er way), some hotkeys that were still somehow working, stopped working. By some wild magic, vesktop running in x11 mode supported some wtype</code>s, but not most. No clue what semantic it used, ngl. You'd think that wtype would be better supported on wayland, rather than x11, so that still throws me for a loop. “Alright” I thought, “That's not a very fruitful thought” the reader replied, — I'll try webcord! I'd much rather be using vesktop; a lot of people I know praise it to heaven, and I've heard of webcord like once or twice. But honestly I just want my symbol hotkeys to work in a discord that is also a separate app, so I'll take what I can get. Except, wtype</code> doesn't work there either :/ I say wtype</code>, but this isn't really program-specific! There's this global linux hotkey ctrl+shift+u</kbd>, that allows you to type in a symbol's unicode, and replaces your input with the actual symbol. wtype</code> uses the same mechanism for inserting the symbol, just skips the unicode input step. This hotkey is really neat actually! I used to memorize unicodes and enter symbols directly using it, in the past 🤓 This was back on x11, where xdotool type</code> was incredibly slow for me for whatever reason; so take note that the existence of the hotkey is not even wayland-specific! The downside of it, as we now see, is that it doesn't work in some (incredibly rare) apps. Anki is one example, but I can easily forgo being able to use my symbol hotkeys there, as I use my own card adding solution anyway, that allows me to use helix instead. But a chat app?... Conclusion: there is no way (yes, dear reader, I'm baiting you to potentially solve my entire problem if you happen to know how) to make wtype work on any discord apps that are worth using. This is a massive dealbreaker for me, soooo I guess I'm sticking with web discord? You'd think I'm saying “aw dang” right about now, but actually I'm not that sad about how this adventure turned out! Sure, I end up without app discord, but in return I learned the difference between https and socks5 proxies, the fact that my proxy is also a socks5 one, how I can make use of socks5 to make the proxy more powerful, and work on mobile, helped a friend cave out of the same awful vpn situation, and learned how to strip my proxy off of its username + password, including now being able to proxy any electron applications, oh and I fixed spotify btw :D using the privoxy trick once again. Similar to my other journeys</a>, the reward of knowledge is much more valuable than the practicality of the result. Hell, I could conceivably sell my knowledge to normies, helping them set up a proxy! Is that a job I'm thinking about? 🤯 Considering the sheer price difference between a vpn, as well as (usually) much better performance, setting up a proxy for someone is a genuine service that will end up saving them money in the long term 🤔 something to think about :> footnotes</a></h1> ^{1 </a> I found this analogy hilarious more than anything, don't take it too seriously :D} ^{2 </a> До сих пор злюсь немного на их ребрендинг. Какой нахуй Т-банк?? Тинькофф звучит намного более приятно.... Это как твиттер → х. Х блять!} ^{3 </a> Благодаря чему эта, казалось бы рисковая, операция, на самом деле безопасная!} ^{4 </a> These are all example values; the “information”s of your proxy will be different, but are going to look about the same, so this serves as a reference.} ^{5 </a> Sheer guess.} ^{6 </a> The wrong spelling is tribute to my friend skoove :3 It's one of her cutest misspellings} Am I overusing footnotes? I feel that you being able to jump back easily makes me spam them a lot more strongly than I should otherwise hahaha ^{7 </a> Reference to}Chuckle Sandwich</a>, while mentioning my puppygirl partner at the same time. harp Axlefublr — Sun, 20 Jul 2025 00:00:00 +0000 Travelling to files in text editors is very slow at best. There are four main ways to travel to a file from your text editor. Let's discuss them. fuzzy picker</a></h1> Your telescope, or snacks file picker; your helix file picker. Your vscode ctrl+p</kbd> fuzzy file picker, even. The classic. You search through a list of all files in the current directory, using a fuzzy search algorithm — you can type aaa</code> and it will match banana</code>. This approch is what neovim users claim to be the silver bullet to file traversal. Something that solves travelling between files quickly and efficiently. “I can get to any file in just a few keystrokes!” is a notion I reject categorically. Efficient fuzzy searching is non-intuitive; it's something you actively learn to do. Think of lsp suggestions. Say you want to complete a function with a really long name: here_is_my_longly_named_function</code>. The efficient approach to matching it is probably going to be himlnf</code> — type in the first letter of each subword, to almost guarantee that it will be the first match. Let's not kid ourselves; this is not intuitive. Despite me knowing the himlnf</code> trick, I'll still naturally start typing here_…</code>, and then complete the name of the function once it appears in my lsp suggestions. Fuzzy lsp suggestion matching is something I have to make the active decision to do. Or perhaps, something that I would have to train myself to always do. I don't think I'm alone in this. I'm not saying fuzzy matching is bad. Hell no! I'll pick fuzzy matching almost always over substring matching. But this is not my point. My point is that efficient fuzzy matching spends mental cycles; in most cases what you'll end up doing is just typing in a substring rather than a heavily optimized fuzzy matcher. Coming back to the fuzzy file picker. Most files in a project you probably don't have to visit often, so simply using a substring is no big deal. But there will be some files you interact with over and over again, where using simply a substring over and over again will become very painful. And that's where you decide to put in the extra mental effort, and figure out an efficient enough, and nice-to-type enough fuzzy matcher. “I can get to any file in just a few keystrokes!” — this is where we disagree: my definition of "few" and your definition of "few" seems to be quite different. Or rather, if "few" is to be taken literally, that's an unacceptable cost to me. From experience of coming up with these good fuzzy matching strings, they tend to be 4-5 characters. We add in the extra 2 keys pressed to invoke the picker to begin with, and pressing Enter</kbd> to accept the result. That is 7-9 keys pressed to get to a single file. SEVEN TO NINE ENTIRE KEYS. Alright fair enough, mister seven-to-nine keys man (what a weird nickname you have, too), I don't mean to yuck your yum. You got your perfect sequence of keys to press to get to a specific file, and now you're golden. Sure, it's kinda a lot of keys to press, but you got it in your muscle memory now, and you're super quick at entering those now! Until tragedy befalls you… You create a new file 😨 What horror! And now it's that file that appears first in the result list, after entering your perfect fuzzy matcher, rather than the file that you were aiming for! And now you sheepishly refine the query you got so used to, to match the old file correctly again. You might've needed to add one or two extra keys to press for the query, too. And the scariest part? In the future, this may happen again… Worse yet, there will be files that you are unable to place as the first result, making you always have to press Down</kbd> or ctrl+p</kbd> or what have you. Obviously I'm being dramatic here, but this both conveys my point and is probably fun for you to read :) Fuzzy searching to travel across files you travel to really really frequently is both inefficient and inconsistent. Reasonable enough for rare files though. Aside from the optimal query being long, it has a pretty big chance to not be enjoyable to type in anyway. It's common that file structures of projects are made in such a way, that you end up needing to match really annoying paths. And you can't exactly optimize your file structure to fit the fuzzying need; at least not for every project. file explorers</a></h1> File trees, or file lists, like oil.nvim</a> (my beloved) — UI that presents the files visually, and tends to allow you to do file operations, like creating new files, deleting them, renaming them, etc, but also opening them. Where these shine is file operations, rather than being a fast way to get to some file. “Open file tree in the parent directory of the current buffer” very much comes in handy to jump between multiple closely related files. Also, using a tree / file list helps to get a better grasp of the overall project structure; something that's hard to do with a fuzzy file picker. But actually ←↓↑→ing through directories and files to jump to some file is of course inefficient — it's more so something you do when you aren't sure what file you even want. In other words, file explorers are good, but for other usecases; not for fast and efficient file traversal. lsp actions</a></h1> Go to: definition, declaration, type definition, implementation; Open fuzzy picker for: symbols in the current buffer, the entire project, outgoing calls, incoming calls, references. All</del> most of those are instrumental for a normal dev workflow, and of course I use them actively. But the reason why they don't solve the entire question completely, is because they are all lsp reliant. You have to have an lsp for the given language, and set up to actually work; also, it needs to implement the above lsp actions. Then, your editor needs to be able to interpret them, too (helix doesn't have incoming/outgoing calls, for example). And even after all of that, lsp tends to take quite some time to start up. In rust, especially, by the time the lsp gives you the ability to use its actions, you probably would've already travelled to the file and place that you wanted to get to, by using any combination of the other methods. Once the lsp is started up and working, the usecase question still exists: you don't always want to jump to a type, or function, or a part of the source code, even. For its intended usecase, lsp actions are very helpful and powerful, but definitely not a generic cure for every usecase. :edit command</a></h1> :edit</code> in neovim, :open</code> in helix; basically, opening a file by typing in its relative (or full) path directly. The big part of this method is the existence of Tab</kbd>. Say you want to complete the path ~/programming/dotfiles/colors.css</code>. You start typing ~/p</code> and press Tab</kbd>. In your home directory, you also have directory progesterone</code>, so you get shown both results; Pressing Tab</kbd> once accepts progesterone</code>, pressing it twice will accept programming</code>. Basically, you have to rotate through the results. However, if you typed ~/progr</code> and pressed Tab</kbd>, now you don't have to choose: there is only one valid match for the substring progr</code>! And it's programming</code>. So, to complete the path ~/programming/dotfiles/colors.css</code> most efficiently, I'd type ~/progr<Tab>/d<Tab>/colo<Tab></code>. You can pretty quickly realize how it's beneficial for a path to become unique quickly; Downloads</code> and Documents</code> both existing make me kinda mad for this reason. While you can optimize directory names</a> like Downloads</code>, Documents</code>, etc to be faster and easier to tab complete (or type in), there will ultimately be some directories that you cannot / should not optimize, like ~/.config</code>, ~/.local/share</code>, ~/.cache</code>. They unfortunately also carry wonderful semantics, that make a lot of sense to make use of. And of course, they are used by all of your programs! But getting to them is a pain! :c With perfect fuzzy queries, you at least have a bit more space to move around in. With tab completing a path, you need to complete each part of the path separately, rather than being able to match the entirety of the full path with some perfect fuzzy query. Considering that it's not often that tab completing supports fuzzy matching, it makes the most sense to get used to (and internalize) perfect tab queries for the paths you might want to travel to often. Why even use this method ever? Fuzzy matching file pickers generally open within your current working directory, and if you're in ~/fes/dot</code> rather than ~/.config</code>, you won't be able to pick a file that's in ~/.config</code>. So that's the main reason you'd ever use :edit</code> over fuzzy picking. Once again, this solution is not the bees knees; matter of fact, it might be the absolute worst approach, depending on how you look at it! :» bookmarking</a></h1> As you find pathing pain points, you might be led towards a certain idea. You find yourself editing some specific config file over and over again; cd</code>ing into some same directory. So you decide to make a mapping in your editor to open that file, And an alias in your shell to cd</code> to the directory. Yay! Now a pain point is gone :» You can navigate to things you navigate to often, quicker and more comfortably. But there's an issue: this method doesn't scale that well. First, you start with having aliases for ~/.config</code>, ~/.local/share</code>, ~/.cache</code>. All directories that you will for sure be jumping to over and over again. But then you suddenly realize you need to jump to a directory ~/.local/share/Steam/steamapps/common/Enter the Gungeon/mods</code>. Navigating into your config (which you have on a mapping, let's say), finding the new place where you'd like to add the alias (unless that's not a problem for you</a>), and typing in that path + the syntax for making an alias is undeniably a bit of a workflow break. It is something you stop to do, and at best will spend 20 seconds on. Then “wait, what was I doing again? ah right”. I experienced this many times. So you might be led to making some hotkey that creates an alias for you, and also adds it to your configuration. But while that solves the stoppage issue, it has another one. You create an alias for that enter the gungeon mods directory, and after some time you realize you don't play the game anymore, and haven't been using its alias for a long time. This alias indeed used to be quite a useful one, but now it's just trash in your shell configuration; something that you need to scroll through / think through when doing something unrelated. Unclean. solution</a></h1> I created a bookmarking system, where I both “get” and “set” the data interactively, on a hotkey, and therefore don't experience any stoppages. The name of each bookmark is simply a key that I press, rather than a name I have to type out. All of these bookmarks are kept in a json file, so that I can easily back them up, and so the same bookmarks could be reused in multiple different programs for possibly different purposes, and different contexts. This is how the program harp</a> came to life. There are multiple concepts that harp the idea (rather than harp the program) brings to the table. First, I need to be able to store multiple separate sets of bookmarks (a bookmark is called a “harp”): in our beginner example, I want a set of harps which stores file paths, and another set of harps that stores directory paths. To accomodate this, harp has “sections”. A section is a namespace, that isolates a set of harps, so that they don't conflict with other sets of harps. So I may have a harp section named harp_files</code> that will store file paths, and another harp section named harp_dirs</code> that will store directory paths. Next, I mentioned that a given harp (bookmark) is named via me pressing some key. I have a harp a</code>, a harp f</code>, a harp ctrl+j</code>. These harp keys / names are called “registers”. You can think of vim registers, that you access via "a</code> — harp registers are a very similar idea. Under each register, we hold some data. So, file path harp a</code> may store the path ~/fes/dot/colors.css</code>. Directory harp alt+k</code> may store the path ~/fes/lai/bog</code> ^{1 </a> . The data of a register is called a “harp”.} Since registers are simply keys that I press, they can start to collide pretty quick: this is why we have sections to separate the sets of registers — I can simultenously have a file harp a</code>, and a directory harp a</code>, and they won't conflict. To accomodate this entire idea, I would need to interact with a HashMap<HashMap<String, Vec<String>>></code> in every program that I want to implement harp in. I would also need to interact with the json file that actually holds this data, deserializing it into the program, and then serializing it again. This is quite doable in some programs, but completely impossible in others; That's where harp the program comes into play: it's a single, simple interface to interact with harps. In most places, I simply use harp</code> as an external shell command, to either supply data, or get data from stdout of. In other cases where I'm editing the rust source code, I can use harp</code> as a library. This ends up making it much simpler and faster to integrate harp into a given program, as all the boilerplate steps are taken care of for me by harp</code>. harp actions</a></h1> Let's start looking into what a harp implementation ends up looking like on a more practical scale, now that we have the main concepts understood. I'll be showcasing the harp implementation I have in my helix fork</a>, but the ideas are quite flexible and can be implemented into other editors and various programs. The main idea of how harp is practically useful is via “harp action”s. Each harp action has a “set” and a “get” method. “set” takes some data from the environment, and stores it. “get” retrieves that stored data, and uses it somehow. file harps</a></h2> The most basic harp action, the one that started it all: file harps. File harp set takes the filepath of the current buffer, and stores it. File harp get retrieves the stored path, and opens it in the editor. Even just this is flabbergastingly powerful. All of your various offshoot config files that you want to jump to frequently? Set file harps for them, and now you can get to them incredibly quickly. Most of what I do is edit config files… So I use this a lot. I have file harps bound on space+s</kbd>, so to get to all of my most wanted files, I only need to press three keys. Helix config — space+s+c</kbd> Foot config (what a strange combination of words) — space+s+f</kbd> Program setups</a> — space+s+d</kbd>; yada yada etc etc. Now, how did I set all of those harps? space+S</kbd> is my file harp set hotkey! pretty natural, right? :3 I get to the file that I want to mark, and press space+S+some_key</kbd>. Similar to how the get action interactively asks me for a key to press, the set action does too. Immediately as I realize I want to access the same file over and over again, I set a harp for it on the fly, and just continue on: I don't need to divert myself into some config file, I just press a key! </hr> </a> I strangely specify “config files”; there's nothing about file harps that enforces you to use them only for config files though! Why did I choose that wording? You will set file harps for the files that you visit the most often, as I mentioned. When coming up with a harp you'll like using for a file, you go through an interesting process. Say I want to make a harp for my helix config. I access it so often that I don't want to press h</kbd> for it, which would be the most obvious key to pick. c</kbd> feels quite comfortable to press, so I'll go with that. I have a file where I store various colors I use often</a>. The obvious harp key for it is c</kbd>, but it's already taken by my helix config! I could of course just move the helix config to somewhere else, but I don't want to: it's far more important and common than going to my colors file. Next idea is to put the colors file at capital C</kbd>, but whoops! It's already taken by my anki</a> css file. That one I could reasonably move as it's not particularly important, but I decide I don't wanna bother right now, and arrive at ctrl+c</kbd>. Because of home row mods</a>, it's actually still quite convenient to press for me, so it's still a good harp key. But you can probably see how, as you harp more and more files, you'll end up making bigger and bigger compromises with yourself, coming up with less and less memorable harps, which ends up in you underusing them — you're never quite sure what that one harp was for that one file, because it's ctrl+alt+y</kbd> or some shit at this point. This poor scalability is the reason why I specify “config files” — within this scope, I absolutely have more than enough potential nice harps to use, and don't have to get to the ctrl+alt+y</kbd> point (unless it specifically makes sense for some given file). But this poor scalability is what will make it unpleasant / unlikely / unreasonable to use harps for temporary-ish files, like files in some project you're working on. Now this is the part where you'll shit you're pants. I solved this. I present to you the next harp concept 🗣️✍️🔥: relativity</a></h1> The default harp relativity is “global” — it's not relative to anything and the sections used for the harp actions are also normal: harp_files</code>, harp_dirs</code>, etc. When you set a global harp, you'll be able to get to it no matter where you are. This is the default behavior for all harp actions. But other relativities, aside from “global”, work in a different way. They limit the scope of your reach depending on some context from your editor. Let's learn with an example. Say I'm working on my helix fork</a>, and noticed a file that I want to harp: helix-term/src/commands.rs</code> The obvious harp key that comes to mind is c</kbd>. But as you've now seen above, all of c</kbd>, C</kbd> and even ctrl+c</kbd> are already taken; And I sure as hell don't want to use alt+c</kbd> for this. The “directory” relativity comes to the rescue! Rather than using the global harp_files</code> section, the directory relativity creates a new section by using your current working directory. I store my helix fork at path ~/fes/ork/hx</code>, and when I open the editor to work on the editor (lol), ~/fes/ork/hx</code> also becomes the current working directory of helix. That is what's used by the directory relativity, and you end up using the section harp_files_~/fes/ork/hx</code>. Notice how the path to the current working directory became a part of the section name! This is how all relativities are implemented :3 What this actually gives us, is the following behavior. I press space+S</kbd> to set a new harp for helix-term/src/commands.rs</code>, and see harp file set (global)</code> in my prompt, notifying me that I'm currently in the global relativity (using section harp_files</code>). Next, I press .</kbd> to switch to the directory relativity, and notice that in my prompt: harp file set (directory)</code> (now using section harp_files_~/fes/ork/hx</code>). I now press the actual key I want to use for the harp — c</kbd>. The harp is now set! And it will not conflict with that other harp I have on c</kbd> for my helix config, because it's stored in a different section! Chances are, if I want to go to helix-term/src/commands.rs</code>, that means that I already opened the helix fork directory and started helix there. So storing the harp for the file globally doesn't really make any sense — it's quite a waste! Storing it “inside” the only directory from which I'll ever want to access it is far more efficent. So, to reiterate, now I press space+s+c</kbd> to harp into my helix config (from anywhere), and press space+s+.+c</kbd> to harp into helix-term/src/commands.rs</code> (from ~/fes/ork/hx</code>). I can create and use project specific harps, resulting in the seemingly restrictive system being quite scaleable! All relativities ^{2 </a> exist for all harp actions} ^{3 </a> . Some relativities don't make logical sense for some harp actions, so I'll introduce the other ones as they come up in usefulness for the other harp actions, as we go.} ^{2 </a> You only know “global” and “directory” so far.} ^{3 </a> You only know harp files and have heard of harp directories so far.} You might find yourself almost always using the directory relativity for file harps; That's a pretty reasonable approach! You can change the default relativity per harp action. For example, you could set file harps to automatically assume the “directory” relativity. Then to access the global relativity again, you'd have to press '</kbd> before the harp key, but would no longer need to press .</kbd> every single time for the directory relativity — that is now your default instead of “global”. As you discover your own harp workflow, you'll find the relativities you use most for each harp action, and will be able to make it more ergonomic and fast 🚀 for yourself :3 directory harps</a></h2> Harps don't have to be exclusive to your editor! This harp action exists for me both in helix, and fish shell! Zoxide is wonderful, but still requires me to type at least a few characters to get to a specific directory that I want. And if I stand my ground and use only one character, it'll likely jump me to the wrong directory; at least, I can never tell ahead of time where I'll end up in, and so it all ends up being a waste of mental cycles. Instead, I use directory harps! “set” takes my current working directory, “get” cd</code>s into it. My shell, of course, has a current working directory; but did you know your editor (helix / nvim) has its own, separate, current working directory? That's the reason I have directory harps for both! I do a lot of configuration, so I always need to travel to my dotfiles directory quickly and directly. Directory harp d</code> lets me jump to ~/fes/dot</code>. My blog, similarly, is something I need to get to often; ~/fes/lai/bog</code> is on harp x</code>. The various notes I have that may or may not be temporary are extra important to be instantenous: ~/fes/foe</code> on k</code>. I fuck up something in a magazine</a> — use harp m</code> to quickly get to ~/.local/share/magazine</code> and git reset</code> some magazine action. I used the keys/letters that were easiest for me to remember for each path, so they got into my muscle memory pretty quickly. I now consistently save mental effort getting to these directories, and can instead think about anything else instead :> I never had to type out any of those paths to set them, either! I simply get to that directory somehow (maybe by using zoxide, too!), then press ctrl+alt+m+some_key</kbd> in my shell. My current working directory is automatically passed, so no need to provide it manually! Then in helix, if I ever realize I need to change directory to one of those paths, I can use the directory harp action within helix — I made shell directory harps and helix directory harps share the same section, so setting a harp in one will set it in the other! Very convenient. The pain point of ~/.config</code>, ~/.local/share</code>, etc, is also completely solved by directory harps! And you get to decide what key makes the most sense to you to press to get to them. With fuzzying, you get your perfect query enforced on you — with harp, you get to name it. ~/.local/share</code> makes you feel like pressing z</kbd>? Sure whatever. ~/.cache</code> is ctrl+alt+h</kbd>? You go girl. I lied</a></h1> None of the relativities are particularly useful with directory harps! So let's talk about a lie I told you. My harp file set hotkey is not actually space+S</kbd>! Changing relativities is not a one time deal: .</kbd> to switch to the directory relativity, '</kbd> to switch to the global one, and other relativities you do not yet know, all act as hotkeys. You press those keys to change your current ‘mode’. What this means, is that you can press them as many times as you want — you can jump between the relativities, doing like 15 “nevermind”s, before ultimately deciding (or cancelling with Escape</kbd>) on the one that you want and pressing the actual harp key. .'.'.''.'.'..'.'..'</kbd> is something you can press in sequence while using a harp action, and it's completely normal. It didn't always function this way, and I am really satisfied with my recent harp refactor that made this behavior possible. I really enjoy not being rushed to pick, and instead be able to stay 🤔ing for a while until I decide. My previous set hotkey was space+S</kbd> at the time, and I quite disliked how I needed to think ahead of time (which is quite unhelix-like</a>) whether I wanted to set or to get. Then also, having to hold shift for the set variants made a certain upcoming harp action kind of not worth it to use, to its fullest extent. And that's why I made the change: Pressing Space</kbd> while in a harp action toggles between the get</code> variant, and the set</code> variant. Instead of pressing your “harp file get” hotkey to open a file, and your “harp file set” hotkey to harp it, you simply use your “harp file” mapping, and then decide. You start off in the get</code> mode, but can press Space</kbd> to go into the set mode. Then if you realized you didn't want to set, you can simply press Space</kbd> again to go back to get. And you can do this infinitely! Very stimmy. relative file harps</a></h2> As I started actively using harp, I noticed an interesting pattern. Project structures are often not that unique! In a rust project, there will always be Cargo.toml</code>, one or both of src/main.rs</code> / src/lib.rs</code>. Possibly .rustfmt.toml</code>. In lua, .luarc.json</code> might be something you want to access every so often. Basically every project will have a README.md</code>, maybe a CONTRIBUTING.md</code>; some of my projects have a RELEASE.md</code> that is automatically attached to the github release. With harp, you might find yourself setting the same relative paths over and over again, per each project. And the file first needs to exist and be open, for you to set it, so that's a lil extra effort as well. Seems like a bit of a waste, no? Relative file harps solve this. When normal file harps store the full path, relative file harps only store the relative path of the buffer, from your current working directory. So say your cwd is ~/fes/dot</code> and you have ~/fes/dot/project.txt</code> open. If you set a normal file harp for it, the entire ~/fes/dot/project.txt</code> would be stored, and you would only be able to travel to ~/fes/dot</code>'s project.txt</code> file. But if you set a relative file harp, only project.txt</code> is stored. And now, whenever you get the harp, you will open the project.txt</code> file of the current project, rather than some exact file. What this lets you do is access files that do not even exist yet! Rather than having to first create the file somehow, you immediately jump to where it would be, and on your next write it will automatically get created. So we're solving two problems here: having to set harps for the same files for every project is laborious</li> having to first create the files to then make harps for is laborious also</li> </ol> To reiterate: use relative file harps when you might want to get to different actual files, but that are of the same structure. Use normal file harps when you want to get to exact files. Here are my relative harps: Register</th> Filepath</th></tr></thead> r</kbd></td> README.md</td></tr> e</kbd></td> RELEASE.md</td></tr> k</kbd></td> project.txt</a></td></tr> g</kbd></td> .gitignore</td></tr> j</kbd></td> justfile</td></tr> l</kbd></td> lib.rs</td></tr> c</kbd></td> Cargo.toml</td></tr> m</kbd></td> main.rs</td></tr> </tbody></table> I underuse relative harps honestly; I should harp some more 🗣️ register harps</a></h2> If you're a vim / helix / kakoune user, you might have noticed how using harps is kinda similar to using vim registers. With vim registers, you access a “key”, and then get text that you can interact with in some way; usually by pasting it. In helix, the contents of your registers do not stay across sessions, making them fairly useless. And that's why register harps is a very useful idea! As I (hopefully) mentioned already, setting a harp makes it instantly available in all sessions, so you don't have to worry about helix “forgetting” the contents of your registers after you exit it. To set a register harp, first simply copy (yank) something to your default-yank-register</code> ("</code> by default (meaning that you simply copy normally, no special magic required)). This is the “context” that this harp action uses for the set action: it takes the contents in the default-yank-register</code>. Later on when you get that register, it places the stored contents back into your default-yank-register</code>, letting you paste them normally. I'm gitty of the power of this harp action, and explaining it to you!! But first, let's introduce another relativity :o filetype relativity</a></h2> You can make a harp relative to the current buffer's filetype. It uses the filetype that helix sets for the buffer, rather than just taking the buffer's file extension! So if you use the filetype relativity on a markdown file, !markdown</code> will be appended to the section name, rather than !.md</code> that you may have expected. The filetype relativity even works for files that don't have a “real” filetype! When the buffer doesn't resolve to any real filetype, its filetype is set to “text”. So, if you use the filetype relativity in an example.txt</code> file, !text</code> will be appended to the section name. To switch to the filetype relativity, press ;</kbd> while accessing a harp action. back to register harps</a></h2> The filetype relativity + register harps lets us create a simple snippet system! For example, I despise lua</a>, and don't like how long it takes to type in the syntax for a function object / closure, and I also happen to dislike the default snippets that the lua language server provides for them. I could yank the following: function() → end</code></pre> (the →</code> there is a tab) And put it into a filetype-relative register harp (just make sure you're in a lua file while you do this). Now I can “summon” it whenever I want, by pressing <space>w;f</code> + the paste key ^{4 </a> .} Pressing 4 keys to get to it may be not worth it for you for the specific example, but you can probably see how a bunch of various language-specific boilerplate you don't like typing out can instead be harped, consistently saving you effort :3 In my personal usage, I find myself using the filetype relativity the most often with register harps, so I set it as my default relativity for them. In other words, getting that function object syntax example is just <space>wf</code> for me. Also, I use register harps really frequently for shebang lines! For example: #!/usr/bin/env fish</code></pre> I store this in register harp #</kbd>, relative to the fish</code> language. Then I store the following relative to nushell</code>: #!/usr/bin/env -S nu -n --no-std-lib</code></pre> Once again, also in harp #</kbd>. So you can create a semantic for yourself that makes it easy to remember the intent behind a harp, yet store many different ones thanks the various relativities. Here, it makes sense for me that a shebang line starts with a #</kbd>, and so I use that key as a neat mnemonic. Making use of easy to remember mnemonics / going with what feels the most natural is a great way to make a good use of harp. </hr> </a> Another good default relativity you could use instead of global, is the directory relativity. Then, by default, you will simply have vim-like registers that are scoped to a project, so you can use them a bit more willy-nillily than global ones or filetype-relative ones, and simply temporarily switch your relativity when you do want those. No need to worry about your registers disappearing, and no need to worry what else you saved for later while working on a completely different project. Sometimes, I keep them for long, though! For example, I keep the syntax required to make a footnote ^{5 </a> in this blog, as two register harps — one for the head part of the note (the uppercase number in the previous sentence) and another for the foot part of the note (what you are jumped to). I need to type in the index myself, so to make it easy to do so, I leave in j</code> in place of the number. Once I paste the syntax, I can hop directly to j</code> to then replace with the index. This workflow makes it much more comfortable to create footnotes!} search harps</a></h2> Whenever you search for something, the search pattern you used is stored in the /</code> register. Interestingly, this works not only for the search</code> action (/</kbd>), but also for the “ripgrep project” action (global_search</code>). When you set a search harp, the regex pattern in your /</code> register is stored. When you get a search harp, the pattern is taken from storage and placed back into your /</code> register. The way that searching and the /</code> register works in helix specifically makes this a very nice to use and flexible functionality. You see, /</code> doesn't store “your last search”, it stores “your search”. So when you change the contents of your /</code> register, you change what you will be searching for when you press n</kbd>/N</kbd>. There's no need for the harp action to automatically trigger a “and now you jump to the match!” action, you get to decide how you proceed. So you can get a search harp, and then decide to jump backwards with N</kbd>, or forwards with n</kbd> — harp doesn't make the decision for you because helix's design doesn't require it to, muah! But another really powerful thing that filling the /</code> register does for you, comes back to global_search</code> once again. If you open global_search</code> and don't type in any pattern yet, it shows the pattern stored in the /</code> register, greyed out. Now, if you press Enter</kbd>, it is automatically accepted as your input. In other words, you could get a search harp, then invoke global_search</code> and simply press enter, to search for a stored query! This capability is not unique to global_search</code> though, as if you press /</code> to do a buffer search, you will also see the same greyed out search pattern that you can accept with Enter</kbd>. Ooooor, you can press Up</kbd> to actually paste in that pattern, for you to edit. Searching and the search register semantics in helix are very clean, as you can see; It is thanks to this that register harps is the first harp action that makes great use of every relativity! Let's go through them. directory</a></h3> The global_search</code> capability lets us have lsp-like capabilities without relying on an lsp! First you notice what things you keep searching for in the project, and interactively try to match them with regex by using /</kbd>. You can take your time doing so, trying out different approaches until you confirm it works by simply n</kbd>ing to it. Then, you set a harp for that, using the directory relativity. Now, whenever you want to search for the query again, you get this search harp you created, open global_search</code> and press enter. Especially if the directory relativity is your default one for search harps, this is not too bad! Considering it's your first result, you simply press Enter</kbd> again, but you don't necessarily have to use this functionality for intentionally a single result. You can also make a query that searches for potentially many things, so that you can quickly gain an overlay over all of them. The simplest example of this in the context of the directory relativity, is checking the usage of some given thing. But of course, if you can use an lsp for this sort of basic functionality, use it. The benefit of using search harps instead is for when you don't have access to an lsp, or it is obscenely slow, or you want to check references for a thing which is not technically a symbol (“get all comments”, as an example). Plus, the lsp starts loading once you're actually in some file, and generally to get all references of a symbol, you need to first arrive at that symbol. There will be some situations where it's just much faster to use a search harp, especially if you keep reopening this given project and travelling to the same thing. filetype</a></h3> We created a basic snippet system with register harps, and now we can use search harps to create a basic textobject system! The idea is pretty simple: you create regexes to jump to some syntactical structures. Here's a search harp I made for rust: -> [^ ]+</code></pre> Using it, I can jump to a function's output type: pub fn count(&self) -> usize { self.count.map_or(1, |v| v.get()) }</code></pre> Here, I would arrive at -> usize</code>. Unfortunately, helix uses rust regex, rather than fancyregex</code>, so backreferences are not possible; I'd like to remove the -> </code> from the selection that's made, but still use it in the pattern — currently that's not a thing I can do. I looked into replacing regex</code> with fancyregex</code> in helix, but I couldn't even figure out where to start, ngl. Maybe in the future, me or someone else will do this, and then search-based text objects are going to become even more powerful than they already can be. </hr> </a> You can jump to the previous / next function using [f</kbd> and ]f</kbd>, in helix. This is pretty neat and useful, but often has inconvenient semantics. Closures generally count as functions, and if you have a function inside of a function, that will count too. While in reality, I want to “jump to the next function” the most often for the usecase of travelling through the file the fastest, arriving at some top level function. Having to travel through every itty bitty closure makes this not particularly viable. We can once again use filetype search harps for this usecase, using a simple pattern: ^pub fn</code></pre> Here I specificially search for all public functions that are top level; So methods wouldn't get caught with this — this can be either beneficial or detrimental depending on what you want, but you have the power to define what exactly you want, by changing the regex! :D Maybe jumping to a function specifically is not that useful to you, but overall being able to jump to the next public top-level symbol is — you could simply use ^pub </code> in that case. Regardless of what you want, you get to decide what search “shortcuts” you have, by creating them all to fit your specific needs. Not having to make do with overly specific design restrictions is part of why I love harp so much. global</a></h3> Coming back to how we used search harps with the directory relativity, we can also make use of global_search</code> with the global relativity. TODO</code>, FIXME</code>, BUG</code>, HACK</code>, etc are something that you may either see or even use in your code, as pointers for things to take a look at in the future. You could make a global search harp for them all (or some of them), to be able to quickly get an overview of all places of note, via global_search</code>. \bTODO|FIXME|BUG|HACK\b</code></pre> …And here you go. So far this is the only pattern that I can expect to be useful in any language and any project, but I'm sure there are more things like that! For example, the [[sort etc]]</code> of my autosorter</a> could potentially be a useful pattern to keep stored 🤔 buffer</a></h3> And now I introduce to you the last, fourth harp relativity: buffer. You can make your harps local to the absolute filepath of the current buffer. You can access it by pressing ,</kbd> while using a harp action. Vim-like marks, inherently, store a line+column position. What this means, is that if you add or remove line(s) before that position, you invalidate the stored position. At best, you'll be slightly off, but at worst you're now storing a completely useless position. With vim-like marks, you will find yourself updating the position over and over again, making yourself disheartened to use marks at all. With buffer-relative search harps, we can implement a marking system that completely avoids this issue. Select some area of your code, that is like a landmark. Then, press *</kbd> to search for it. Now if you set a search harp for it relative to the buffer, you can invoke it at any time to quickly jump to it! I use this so frequently, that buffer relativity is my default one for search harps. Thanks to *</kbd>, you don't actually need to enter the search pattern yourself a lot of the time, making the set process quite comfortable. In this same sense, you can consider how helpful it can be for the previous relativities of search harps, too. To show how I use buffer-relative search harps, let's take my helix config generating script</a>. To define my mappings, I have hashmaps per each mode combination that I want to have mappings for. Basically, I can just add a mapping to normal_select_mappings</code> to add it to both modes, rather than having to separately add it to normal_mappings</code> and select_mappings</code>. Since all of these hashmaps are huge, it's incredibly helpful to be able to jump to each of them individually. The variable definitions are unique, and that helps them be unique search patterns! normal_select_mappings: dict[str, Any] = { normal_mappings: dict[str, Any] = { select_mappings: dict[str, Any] = {</code></pre> With all of them, I can simply select the entire line and press *</kbd> to search for it; This way, I can make a search harp with no extra hassle. I'm not going to a line+column position, but searching for normal_select_mappings: dict[str, Any] = {</code>. Thanks to it being a search, I will always land at where the landmark is actually located, not at where it was located. You don't necessarily need to only match a single thing, though. You can also make a buffer-relative search harp that can take you to multiple places. I have two layers in my kanata config</a>, that let me launch programs quickly. In the config file, I might want to jump to either of the two layers, and so I unify them under a single search harp! This is how the two layer definitions start: (deflayermap (apps) (deflayermap (apps-revengeance)</code></pre> So I can use the pattern \(deflayermap \(apps</code> to grab them both in a single search harp, and then simply press n</kbd> to get to either one I want to get to. Aside from being genuinely specific to some file, the buffer relativity can act as your “I really don't wanna think about harps conflicts right now” relativity, that you can use for the truly ad-hoc harp that you don't intend to use later. mark harps</a></h2> Search harps for navigating to some specific place, still, are best suited for things that you intend to get back to at least every so often. After all, you need to think about whether the given search pattern will stay valid (are you sure you aren't going to change the contents of the line you're using as a landmark?), and you do need to press an extra key (n</kbd> usually) or even multiple keys (when using global_search</code> + searh harps). But for ad-hoc things (“I just need to store this position quickly, I'll come back to it in a sec”), or for things that you're sure will remain unchanging for the most part, mark harps are a better pick. Setting a mark harp stores the filepath of the current buffer, and your line + column position in it. Getting a mark harp opens the stored filepath, and travels to the line + column position stored. This makes it a much better ad-hoc harp action, as to set one, you don't need to come up with an appropriate search pattern, you simply set and go on with your day. The position invalidation argument I made in the search harp section still remains true, so mark harps are best used for when an invalidated position wouldn't matter that much. The helix jump list is not trustworthy, it keeps invalidating itself for seemingly no good reason. And when it invalidates, the position you explicitly stored with ctrl+s</kbd> is simply gone, rather than just off, like it might be with mark harps. I find the directory relativity to make the most sense as a default for mark harps ^{6 </a> . You scope your ad-hocs per project, so you never need to worry about overriding something you were working on 5 seconds ago, in a different project. Yet, it's not as restrictive as defaulting to the buffer relativity: since mark harps remember the buffer path as well, you can more freely express “wherever I last been” — you don't need to first remember which file you were in, to then jump to a position inside of.} This harp action is the most recent, actually! Search harps are so good, that I didn't feel the need for this harp action to exist; I also trusted the jumplist more than I should have. Pressing an uppercase letter to set something this “fast”, also felt like a bad value proposition. So it's this harp action that sparked the “space to toggle get/set” change, as well as the refactor that made it possible. Now that I have mark harps, they're really nice! Being able to turn my brain off and not worry about losing my train of workflow is really convenient. command harps</a></h2> On set, the last command mode :command you executed (stored in the :</code> register) is stored. On get, it is executed. In classic harp fashion, the process of setting is interactive. First, you try out the command, until you finalize it into the one you want to store. Only after do you actually “commit” it. If I just made you enter the command into an inputbox, you could have a typo, or simply be using the command incorrectly, and never be the wiser! At least, not until the next time you plan to use that harp, where it may be crucial to not distract yourself with fixing some harp command :p Of course, there might be some commands that you want to store without necessarily running them first; Something destructive perhaps? For those usecases, you can simply write out the command in some buffer, and copy it directly into the :</code> register. That will allow you to fill the “context” that command harps use, without running the command just yet. </hr> </a> This is by far the most powerful harp action, and is my second most used one, after file harps. The kakoune design, that helix takes after, makes storing :commands quite flexible. First, helix has command expansions. Variables that expand to some string, depending on some context. The most useful one that immediately comes to mind, is %(buffer_name)</code> — it resolves to the path of the buffer. Through trying it out, though, I found it largely inconsistent and strange, so my fork adds the following 4 useful command expansions: full_path relative_path buffer_parent working_directory</code></pre> You can probably guess what they resolve to; otherwise you can read about their semantics in the readme of the fork</a>. I believe that command expansions can be used in any :command. But there are a couple of most useful ones. :run-shell-command</code>, or just :sh</code>, lets you execute a shell command asyncronously, and will show its output in a popup, once it finishes. You don't always want to do things asyncronously, though; We can use the %sh()</code> command expansion for the syncronous usecases! %sh(echo hi)</code> will execute the shell command echo hi</code>, wait for it to finish, and then resolve to the output. The call of a :command itself is syncronous, so %sh()</code> must resolve to a value before the :command that contains the %sh()</code> actually runs. To make use of this property, you have the :echo</code> command. It displays the arguments given to it in the messages line (rather than in a popup). You can use %sh()</code> inside of :echo</code> to effectively mimic :sh</code>, but ensure it's syncronous. This little bit of knowledge may especially be useful for your mappings, not just harps. :noop</code> is exactly like :echo</code>, except it doesn't show the output in the messages line. It's made basically specifically for doing %sh()</code>, but when you don't care about the output. :insert-output</code> and :append-output</code> are like :sh</code>, but will insert the output of the command before/after the cursor; syncronously. :pipe</code> pipes the contents of your selections into a shell command, and replaces them (contents) with the output of that shell command. Each selection is piped individually, rather than collected somehow. :pipe-to</code> is the same thing as :pipe</code>, but the contents of your selection(s) are not replaced. Basically, you can use your selection(s) as input to a command, without caring about the output. With such powerful building blocks, you can create quite complex editing actions, without the editor having to provide them for you. However, typing in a lot of powerful commands can quickly become impractical. Sure, you can :pipe</code> into shuf</code> and not worry much about it ^{7 </a> , but what about more complex commandlines?} For really really common things you do you might create hotkeys. But for many other ones, doing so is highly impractical for many different reasons! Having to modify your config for something you aren't even sure you're going to use yet, is painful. If that hotkey is actually project specific, now you're polluting a project with yet another config file (for helix). What if you only need this command for this specific file, or for a filetype? A lot of power that's impractical to use is a good hint that harp could make it a lot better. And oh god does it do exactly that! global</a></h3> You might want to :toggle-option</code> something in a highly specific way, that doesn't happen often enough to warrant a hotkey. For example, I don't use my left gutter at all. But I could foresee wanting to temporarily enable it to see the git hunks in a buffer. I used to have a hotkey for this, but I found myself using it so rarely that I kept forgetting what the hotkey is. That's because all the other, more convenient / easy to remember hotkeys are already occupied by other things, so the “toggle gutter” hotkey is in a rough spot. I can now simply move it to be a command harp, on something like global harp g</code>, and be quite happy about it! My :write</code> hotkey is just '</kbd>. Just a few days ago, a new flag has been added to :write</code>, that allows you to write without formatting the file first — --no-format</code>. This sounds pretty useful of a thing! But I'm not yet sure if I'd actually use it in my workflow. So I can blammo it on global command harp w</code> and let time tell me if I need the functionality or not. This is because I will never bother typing in the long ass --no-format</code> flag normally — I need a shortcut of some kind to even consider using the feature. Being able to “try out” things before considering putting them into your direct mappings, I've found to be incredibly helpful. :open</a></h4> Command harps are so powerful that they can completely mimic a whole entire different harp action! /hj The :open</code> command lets you open some file, which is exactly what file harps do. You could, if you wanted to, make a command harp that :open</code>s some file, which is really funny. But there's a genuine usecase for this, too — opening directories. If you try to :open</code> a directory rather than a file, a fuzzy file search is opened for that directory instead ^{8 </a> So if you keep finding yourself specifically fuzzy searching for files in some directory, making a command harp with :open</code> for it could be a pretty great solution.} Directory harps exist, sure, but they are more so meant to travel to directories that you intend to stay in. If all you ever want to do is open a singular file in a directory, travelling to it, opening the fuzzy finder, and then :cd -</code>ing feels like a bit of a waste. ^{8 </a> Fun fact: this also works on the commandline. helix .</code> will open helix, and immediately launch the file picker, for example.} filetype</a></h3> The filetype relativity is where it's really at. You can make harps harps to do language-specific run-like things. Almost every filetype you can “run” in some sort of sense. Interpreted languages usually go like :sh intlang %(full_path)</code>. Compiled languages want you to compile and then run the file, so that's something like :sh complang compile %(full_path) ; ./build/debug/bin</code>. Some have a convenient command to compile+run in a single step, like :sh coollang run</code>. For something like html, you might just want to use your browser with :sh xdg-open %(full_path)</code>. And that's just “run”! You don't have to stop there. You can have filetype command harps for “lint”, “build”, “build but use pueue</a>”, “test”, “open docs”, “pipe my selection into the interpreter, rather than the whole file”, and any other language specific actions that you might wanna do. What I recommend for this workflow, is to try to use the same keys for the same sort of semantic, so that they're easier to remember. Just like always using #</code> for the shebang register harps, remember? My “run” is always on s</code>, my “open docs” always on d</code>, “build” always on b</code>. </hr> </a> :pipe</code> can come in useful for implementing custom code actions, by using a custom script. You could use :insert-output</code> as a way to generate some boilerplate for a language (if, for example, it is not static (where it'd make more sense to use a register harp instead)). As an example, you could make a command harp that generates the java class boilerplate. Usually the name of the class is the same as the name of the file, so you could use %sh(full_path)</code>, then extract the basename, and pass it on to your script that outputs the boilerplate. If the input to the script is not deterministic like that, you could instead use :pipe</code> — Type in the input in the buffer, then select it and use the command harp that :pipe</code>s it into the afforementioned script. Thanks to all this, filetype-relative command harps can become a very useful extension to your lsps. directory</a></h3> Some actions are project specific, not just language specific. To “run” a markdown file, I'll probably want to convert it to html and open that html in my browser. For this blog though, I use zola</code></a>. So, I made myself a directory-relative command harp that “compiles” the blog with zola and opens it in my browser. Because of treesitters, I can't just cargo build --release</code> my helix fork normally, so my language-relative build harp for rust isn't sufficient. And so, I have a project-relative harp to install my helix fork. It doesn't have to be so language action focused, though. Ultimately, if you find yourself running some command frequently, shell or not, for a given project, directory-relative command harps can help you. You can think of them as your personal justfile directly in your editor, that you don't need to gitignore or commit upstream. buffer</a></h3> You can sometimes find yourself doing hyperspecific transformations in specific files, over and over again. In my loago ^{9 </a> helper script, I have this section…} const known = { razor: 4 bed: 6 towels: 7 vacuum: 8 update: 10 bottle: 15 keyboard: 30 filter: 45 fsrs: 60 toothbrush: 122 }</code></pre> …That I constantly want to sort by the numbers, rather than key names. I don't know of a way to express this semantic directly (and so I'll write a crystal program for this eventually), but in this file specifically all the numbers are the second field. So I can use :pipe sort -nk 2</code> as a buffer-relative command harp, to solve this usecase 🥳 This is pretty convenient — instead of feeling rushed to create a generic solution for the problem, I can for now make a hyperspecific one, and use the buffer relativity to store it in a convenient way. conclusion</a></h1> This is the conclusion part of the blog post, that sums up everything you've read, and provides an emotional release to all the effort you've spent reading. It creates a logical stop to the experience, naturally leading you to exclaim “wow! what a read”, or some such. </hr> </a> I've been on and off writing this blog post for over 50 days so I wanted to spare myself writing a genuine conclusion hahahaha I'm sure you're tired from reading, too, genuine thank you for taking the time. Hope you can now take the harp concept, and make it as, if not even more useful for yourself, as it is for me. sike</a></h1> I come back yet again! It's now 2025.12.10 (i.e. almost half a year since this post's initial release), and I have new thoughts (and features :o) Harp doesn't have a “view all currently set registers” feature, half on purpose and half due to my laziness. If you are given a chance to look at your existing registers, you will ultimately feel encouraged to clean them up all the time. It can feel like a bit of a waste of time, considering how relativities give you essentially infinite registers, that you'll then indefinitely clean. My thought process was that if you need some sort of view to remember what key you placed some harp on, it's probably because you placed it on an unmemorable key, and should instead re-make the harp on a better one. This is the hotkey master in me talking, mainly: the thing I am best at, is creating hotkey systems. So both creating memorable hotkeys and remembering them is my forte. My thinking works quite well for most harp actions. There's not much effort in making a file or cwd harp for example. But once you get into the more fancy harp actions, my approach starts to crumble. Making any harp is somewhat of a mental energy investment: “what key should I use, that feels the most ‘correct’ for this file / working directory / search pattern / etc?”, “what relativity should I use for this?”, “should I store this as a mark or as a search harp?”. This investment is worth it mainly because of how much mental energy you save in the future, over time. You decide to pay this price, and make a somewhat complex / long command harp. It sets up the testing environment for this project in some specific way, massively helping you iterate on it faster. You use it quite a lot, feeling sheer bliss over how productive it helps you be. But new excitements come! You switch to working on a new project for a while, with it own harps and gimmicks. Many months go by, and you come back to the first project again. “Uhhhhhh what was that useful harp again?” ^{10 </a> — you try the most likely key that you might've placed it on, but it does a completely different command, maybe starting some build that now you need to annoyingly figure out how to cancel. “Hmmm what about this one?” — ‘harp h</code> unset’ it tells you.} Well... I don't want to just keep mashing keys until I find it. Maybe some of my command harps are quite destructive, after all. Ugh, it's frustrating but I think it's not worth trying to re-find the harp, let me remake it again. But here's a caveat when it comes to making things, as a developer. The first time, the energy investment is fueled by your excitement at how cool the thing you're creating is going to be. For example, you're learning nushell! And making this specific command is great practice that you're quite pumped for. But the second time solving the same exact problem, you're not quite as excited. Well, it would be one thing if it was the same problem, but no you solved LITERALLY this already, so it feels even worse to have to redo. This wouldn't matter much if the command was short and simple, but you made quite a bit of a monster of a command harp. It inserts the dates in some specific way, autofills some info by curling an api, and even does your dishes for you. “Grrrr I don't wanna do all that again”. You toss it up as a skill issue with using harp and do indeed do it again. But this experience will be remembered by your psyche. Maybe next time, you won't feel so ready to make a harp as complex. “What if I lose it again?” </hr> </a> Yes, what I noticed over months of using harp, is that the current system discourages you from using harps to their full potential, hilariously. You will be taught to only make harps that you're sure you can remember, or only if they're easy enough to remake. The latter type you end up using once and never again, because it's too much of a pain to try to remember where you put them. What's the point of all these infinite potential keys if my human brain can only remember a subsection of them! NOT ANYMORE! Now harp actually does show you all of the set registers you have. In every harp action, in every relativity. You don't need to go into some submode to take a look — they are displayed to you automatically in the whichkey-like window ^{11 </a> } Now you press your hotkey for command harps, and immediately see all the registers you have for your default relativity (which let's say stays global</code>). You press .</kbd> and go into the directory relativity: the whichkey window changes to now show the command harps in the directory relativity. You can keep changing relativities, or get/set, and throughout all of that, the whichkey menu will continue reminding you what you currently have set. This reopens harp possibilities to insane extents! I've already noticed just how much more harps I'm using, thanks to me never losing any. If I can be sure I can keep the harp with me forever, I feel a lot more encouraged to completely abuse them 🚀 (which is the whole point!!) I forked a gtk theme and am “fixing” it; but the file is fucking six to seven thousand lines long so it's a massive pain in the asss to traverse. Despite that, before making this whichkey feature, I was rawdogging travel for the most part! No harps for what can so benefit from them. But after implementing it? Oooh boy! I made a command harp to reopen gtk3-widget-factory on loop for me (useful to test how my changes look), started using marks a lot more frequently for quick “remember this position” movements, made command harps for converting colors (no hsl in gtk3 😭), register harps for common colors I'm using in the theme, and now also search harps to jump to various rules quickly. I am now actually living the harp dream, making use of them as much as I intended for them to be used. I used to say quite frequently: “oh yeah even I underuse harps, I should use them more” — this was due to a misdesign! </hr> </a> Even before reigniting my usage of harps, I noticed how uncomfortable it is to switch relativites, with them all being on keys that aren't on the home row. ,</kbd>, .</kbd>, ;</kbd>, '</kbd> all make sense as defaults, but if you use relativities a LOT, pressing those keys becomes jarring after a while. I changed them to j</kbd> → buffer, k</kbd> → global, l</kbd> → directory. Yay, now they're all on the home row! And are a lot more pleasant to reach thanks to it. But they are ridiculous as defaults... Because now you can't use j</kbd>/k</kbd>/l</kbd> as registers! I'm okay losing out on that, but forcing you to, too, feels pretty wack. So now the hotkeys are configurable! You can decide for yourself: what keys switch to what relativity, what key switches get/set (instead of Space</kbd>), and what keys do the mystery XXX and YYY I'm going to explain in the next section. The defaults stay the “reasonable but kinda yuck to use” ,</kbd>, .</kbd>, ;</kbd>, '</kbd>, Space</kbd>, for the record. </hr> </a> Now that you can view your set registers, you have to be able to delete some of them, too; so that all the ones you are no longer using aren't creating a visual mess that takes up half your screen. I do still think that it's unfortunate that you'll be encouraged to clean things up (often a bit of a waste of time), but it's just SO worth it considering how much more easily you can rely on and abuse harps, now that you can see them. When you invoke a harp action, you start in get</code> mode and get a view of all of the set registers. At this point, you can press Backspace</kbd>: after that, the next key that you press will get deleted, the ui will update to reflect that deletion, and you'll go back to get</code> mode. So del</code> is a new mode, along with get</code> and set</code>, but unlike the latter two, it only stays for a single key and doesn't finish / close the harp action (only brings you back to get</code>). So you can press Backspace</kbd>a</kbd>Backspace</kbd>b</kbd>Backspace</kbd>c</kbd> to delete three different registers in a sequence — you enter the del</code> mode three different times here. At first, I made the del mode “stay”: once you pressed Backspace</kbd>, all of the following keys would be deletions, and you'd need to press Space</kbd> to go back to get</code> when you wanted to. Very quickly I started to accidentally delete harps that I was meaning to get</code> 💀 So I changed it to the “chord the next key” variation that is the current behavior — it seems a lot more natural. If you press Backspace</kbd> and go “nevermind actually”, you can go back to get</code> without deleting anything by pressing Space</kbd>, or close the action altogether by pressing Escape</kbd>. There will be some situations where you want to delete all of the registers in a section, and for that you can press Alt+Backspace</kbd>, instead of spamming Backspace</kbd> + a key. That hotkey works regardless of the mode you're currently in (get / set / del), and will put you into set</code> after clearing the registers. The thinking here is that you're probably cleaning things up because you want to set a new harp on a blank canvas 🎨 These two hotkeys are the mystery XXX and YYY I mentioned! So you can change them too 😌 footnotes</a></h1> ^{1 </a> To your possible surprise, yes this is a}real file path</a> I have. It's for this blog! ^{4 </a> Which is p</kbd> for you, but o</kbd>}for me</a>. Also, you don't necessarily have to paste it. You can replace your selection with it, for example! So register harps simply blammo the text into your default-yank-register</code>, and then you can use it how you normally would — no specialcasey usage required! ^{5 </a> Like this one!} ^{6 </a> The global one is still the actual default though, as usual.} ^{7 </a> Although my fork introduces a :random command that lets you randomize the contents of your selections, rather than specifically lines.} ^{9 </a> A chore-tracking program of mine that I will eventually write a blog post about.} ^{10 </a> Hell, do you even remember that that harp exists?} ^{11 </a> I'm referring to the menu that appears on the bottom right when you use chorded mappings, or when you try to select_register</code>. In helix terms, its proper name is auto-info</code> — which is a stupid and unmemorable name.} zoxide misbehavior Axlefublr — Sun, 08 Jun 2025 00:00:00 +0000 I just found a very surprising behavior zoxide gives fish users, that might be part of the reason why zoxide always felt so useless to me in the past. I noticed that one of my directories spiked up in its weight every so often; consistently it would get to the maximum, 9999, while I for sure didn't zoxide to it nearly that often. The reason why this is an issue, is because of how zoxide cleans directories: If a directory's weight is too small, compared to the highest directory, the directory may get removed from the zoxide database, being considered unimportant. But I don't even need the spiking directory to be zoxided at all! I navigate to it using a different method of mine, that I'm currrently writing another blog post about. So having it destroy the other directories, that I do heavily want zoxided, is quite problematic. I looked through all my config, and all the places where I use the z</code> alias — none of them could've led to me spiking that directory. The directory I'm talking about is magazine</code></a> — every time I modify a file in that directory, a fish function gets ran that cd</code>s into the directory and makes a commit. I made sure that it uses specifically cd</code> rather than z</code> when I made it, because obviously I don't want to spike a directory due to a non-interactive, automated action. So I decided to look into what fish code the below line in my config actually executes. zoxide init fish | source</code></pre> My assumption was that it gives me the z</code> alias, which increments directories I travel to using it. But imagine my terror when I realize that it's not the semantic it actually uses! zoxide init fish</code> actually installs a hook on the $PWD</code> variable; Every time your current working directory ($PWD</code>) changes, that directory is incremented. There is nothing about the z</code> alias in specific that increments directories — any method of getting to them does! That is in theory nice, but in practice it easily makes various directories spike up unfairly; if you do any sort of automatic / non-interactive scripting, you might be affected by this. The simple fix for this issue is to do the following instead: if status is-interactive zoxide init fish | source else alias z cd end</code></pre> If you are in an interactive shell session, initialize the hook and give me the z</code> alias. If not, make z</code> just act like cd</code>. This is pretty good, but leaves a poor taste in my mouth. The semantic in my brain is: “If I'm using z</code>, that's because I want to increment the directory. If I don't, I use cd</code>.” I very much may want to zoxide increment some directory non-interactively too! A simple usecase I can immediately think of, is some script that sets up all active projects I'm working on, and zoxides into all of them so that I can jump to them later more easily. If I can come up with a genuinely viable usecase like that on the spot, I'm sure that there will be other situations where I don't even realize I want to zoxide! I feel it's much better to just carry the simpler semantic of “z</code> to increment, cd</code> to not”, rather than “z</code> to increment, unless it's not an interactive session, …”. Here's what I put into my config, to achieve that: zoxide init fish | source function __zoxide_hook end function __zoxide_z set -l argc (builtin count $argv) if test $argc -eq 0 __zoxide_cd $HOME else if test "$argv" = - __zoxide_cd - else if test $argc -eq 1 -a -d $argv[1] __zoxide_cd $argv[1] command zoxide add -- (__zoxide_pwd) else if test $argc -eq 2 -a $argv[1] = -- __zoxide_cd -- $argv[2] command zoxide add -- (__zoxide_pwd) else set -l result (command zoxide query --exclude (__zoxide_pwd) -- $argv) and __zoxide_cd $result and command zoxide add -- (__zoxide_pwd) end end</code></pre> Notice how now the | source</code> line runs always, regardless of if I'm in an interactive session or not. Then, I disable the $PWD</code> variable hook. Doing so makes z</code> practically just act like cd</code>, so to give it back the power of incrementing, I add in command zoxide add -- (__zoxide_pwd)</code> in the branches where incrementing makes sense. In the future, zoxide devs might update the __zoxide_z</code> function to make it better in various ways; So if you're reading this blog post in the future, let me explain how I figured out which function to even modify, so that you can recreate it, rather than copy a possibly outdated version directly above. First, do type z</code> — this will show you that z</code> is a fish function, that calls __zoxide_z</code> inside of it. Now, do funced __zoxide_z</code> to open the function's source in your editor; Copy it to your clipboard so that you can blammo it in your config.fish</code>. Add the command zoxide add -- (__zoxide_pwd)</code> to the various branches similar to how I do above. To find the function that sets up a hook in the first place, I simply piped zoxide init fish</code> into my pager, and looked through the code. I noticed --on-variable</code>, and the rest is history. The reason why we aren't just modifying the functions directly with funced</code> (which you can usually do), is because they're defined dynamically every time you run your shell, rather than being funcsave</code>d and staying as a file. So if we were to edit the functions directly, they'd only stay modified for the current session, rather than all future sessions. That's why we need to blammo directly into our config. Now that things are working correctly, I can finally trust zoxide to work as expected. I won't have to worry about initialized directories randomly disappearing, and with another thing I did</a>, my zoxide is overpowered now. 🍐🚀 optimizing paths Axlefublr — Fri, 06 Jun 2025 00:00:00 +0000 The default paths that you start with, and the paths you might end up creating naturally, can be quite inconvenient to work with. In your home directory, you probably have Documents</code>, Downloads</code>, Pictures</code>, Videos</code>, etc. To follow the semantic, you might create directories like Programming</code>, Notes</code>, and the like. All of them are pretty long words, and annoyingly they all start with an uppercase letter: neither of that helps if you need to type out full paths to things pretty often. Unfortunately I do: my biggest usecase is how I handle program setups</a>, but typing out paths comes up in all sorts of places. ~/Programming/Projects/Mine/Rust/2025</code> quickly becomes up exhausting to type in, over time. Tab completing paths helps, but has other issues that I'll go over in another upcoming blog post ^{1 </a> .} To minimize effort of typing in paths, as well as travelling to such paths, some time ago I renamed most of my directory structure to all be single characters, basically. Look at the tree below: ~ r forks proj binaries backup info i tools e memes themes logos icons s screenshot1.png screenshot2.png screenvideo.mp4 q torrent.torrent w random-download.jpeg</code></pre> The core directories, that I'll be typing in the most often, are all single characters. But deeper directories are named normally. This worked pretty well! Now to get to my screenshots directory, I simply need to type out ~/i/s</code>, rather than ~/Pictures/screenshots</code> ^{2 </a> . But there are two things that this approach misses.} First, it's ugly. Seeing ~/r/proj/harp</code> in my prompt just feels kinda bad :/ It's extra uglified by the fact that the core directories are single letters, but deeper directories aren't, so the path ends up looking unbalanced. Second, it's a massive pain for search for. If you want to look for Pictures</code>, you might need to filter out the normal word “pictures”, sure, but ultimately you're still narrowing things down somewhat. But searching for i</code>… I can do i/</code>, but then I'm making the assumption that I immediately refer to another path fragment that is in i</code>. I could /i</code>, but then I'm possibly missing myself programmatically appending the path i</code> to my home directory (think home_dir + "i"</code>). \bi\b</code> will show me way too many results. So no matter how I search, I either have to filter through too many things, or I possibly miss some cases where I do still use the path I want to search for. Additionally, I'm not doing zoxide any favors. The core directories might as well be impossible to zoxide to, since their queries would be so non-unique; but they're short specifically so that I don't have to use zoxide to get to them, to be fair. But then the deeper directories come back to being normal, common words, so zoxiding to them is also a pain, just of a different genre. Yesterday, I decided to take on the grueling task of renaming and restructuring directories in my ~</code>, to handle all of my concerns. I had multiple requirements for the new names: Has to be a short name, but more than 2 characters. It will still be fast and easy to type in, while not looking too unbalanced and ugly.</li> Has to be gibberish. Making it way easier to search for precisely, and making it ideal for zoxide, as a nice side bonus.</li> Has to feel nice to type in. Following the point that paths are something I'll be typing out again and again in the future, I should have a comfortable time doing so.</li> </ol> Here's the tree that I ended up with: ~ fes ack bin dot eli foe lai ork wks go iwm dls lwkc msk osl rnt sco tox twemoji vdi wlx</code></pre> As you can see, almost all of the directories are complete gibberish. Except go I guess. They really couldn't've made it .go</code> instead 🙄 I sat down, and naturally followed where my fingers like to go after typing each letter. After I type f</code>, what letter feels nice to type in next? Then, I considered what directories are going to come after which directories. fes</code>, for example, will be coming after typing in ~/</code>; both ~ and / are on the right side of the keyboard (for me), so that's why fes</code> is so left-focused. All the directories inside of fes</code> will come after fes</code>, obviously, so now I optimize their names according to that. After a heavy left-side, I now introduce the right side keys quite a bit more. I figured out what felt good by repetitively typing in the full path to the directory, and feeling it out. For example, fes</code> was first int</code>! ^{3 </a> But after typing it out a bunch of times, I noticed that pressing n</code> so close after ~/</code> simply didn't feel that good; which is a big nono for such a core, commonly typed directory. Additionally, int</code> is a real thing that may come up in searches, as a false positive, so that's another reason to not use it.} After making the highest level directories, I went on to rename a bunch of directories inside of there. Look at a tree again, but now with context of how the directory used to be called. ~ fes <- r ack <- backup bin <- binaries dot <- dotfiles eli <- auto foe <- info lai <- proj ork <- forks wks <- wks, actually. this one hasn't changed go iwm <- i dls <- didn't exist lwkc <- we don't talk about this one msk <- mus osl <- e rnt <- q sco <- s tox <- tools twemoji vdi <- v wlx <- w</code></pre> You can see how a bunch of the directories took their previous name in some form, and either expanded it or collapsed it, making sure it's gibberish. tools</code> is a common word -> tox</code> is shorter and not a real thing. documents</code> is another word -> dls</code> is unique and nice to type in. backup</code> may even genuinely be used as a directory name all over the place -> ack</code> now has a subdirectory named tua</code> which is hilarious. All of these directories I can now effortlessly zoxide to, or type in manually without complaining about it. I found a great balance. A question you may have now is "how the hell will you remember all of these?" — that's why the naming stage is so important to take seriously. When creating a directory name, I let the purpose of the directory guide me into naming it naturally. Basically, ork</code> feels correct to me to contain my forks, and so is easily memorable. lai</code> is nonsense, but it looks beautiful to me; that is what makes it makes sense to me, for the purpose of storing my projects. Because fes</code> used to be int</code>, foe</code> is now really memorable to hold “info” — the path int/foe</code> is peak comedy to me. Similarly to ack/tua</code>. This is why I cannot give any specific suggestions to what your directory names should be; what feels correctest to you will be similarly heavily personalized. I hope I could inspire you to rethink your directory structure, to make it more enjoyable to traverse and look at. footnotes</a></h1> ^1 </a>Here it is</a> ^{2 </a> I'll talk about zoxide later, don't worry. Part of god's plan.} ^{3 </a> The subdirectory eli</code> comes from a pun based on the upper directory being named int</code>. If I named a future project gents</code>, I'd have a path ~/int/eli/gents</code>. Which is of course hilarious.} autocurling Axlefublr — Tue, 13 May 2025 00:00:00 +0000 Often times, various programs don't provide you a way to look at the default config file locally, but do provide one in the github repo. Having to 1. need internet and 2. use my browser to get to some default config is quite meh. The documentation being the readme falls into a similar issue. Cloning the repo so that you have it locally is overkill, too. Let me explain the idea of how I solve this problem. You can curl</code> files directly from github ^{1 </a> by converting a normal link to a file into its raw version:} https://github.com/Axlefublr/dotfiles/blob/main/kanata/kanata.kbd</code></pre> …Turns into… https://raw.githubusercontent.com/Axlefublr/dotfiles/refs/heads/main/kanata/kanata.kbd</code></pre> So, you replace github.com</code> with raw.githubusercontent.com</code>, and replace blob</code> with refs/heads</code>. I wrote a fish function that takes the link from stdin, and converts it for me: function lh read | string replace 'github.com' 'raw.githubusercontent.com' | string replace blob refs/heads end</code></pre> Which is useful because in helix, I can pipe my current selection(s) into a shell command, and replace them with the output, letting me transform github links I copied pretty painlessly! So, once we get the raw link, we can curl <the-link-here> -o output-file</code> to grab a remote github file into a local one. This is pretty awesome! But just grabbing the file once is not enough — it can become outdated. My idea is to store all the links I want to keep locally, so that they can be updated daily automatically. Using a magazine</a> is awesome for this usecase, as it's both easily accessible and modifiable — adding new links isn't going to be bothersome. My magazine C now contains this: defconf/waybar.jsonc https://raw.githubusercontent.com/Alexays/Waybar/refs/heads/master/resources/config.jsonc defconf/niri.kdl https://raw.githubusercontent.com/YaLTeR/niri/refs/heads/main/resources/default-config.kdl defconf/dunst.ini https://raw.githubusercontent.com/dunst-project/dunst/refs/heads/master/dunstrc defconf/ov.yaml https://raw.githubusercontent.com/noborus/ov/refs/heads/master/ov.yaml source/systemd-exponential-restart.c https://raw.githubusercontent.com/systemd/systemd/refs/heads/main/src/core/service.c</code></pre> First, I specify a path to where the file should be downloaded; then the actual link. The path is relative to ~/.local/share/frizz</code> — a directory I created specifically for files that will be downloaded like this. I then have a fish abbreviation (similar to an alias) that cd</code>s me to that directory and does helix .</code> — I can quickly open a new terminal and instantly fuzzy search through my downloaded files this way. ^{2 </a> } function frizz for curlie in (tac ~/.local/share/magazine/C) set -l bits (string split ' ' $curlie) curl $bits[2] --create-dirs -o ~/.local/share/frizz/"$bits[1]" end notify-send frizz end</code></pre> This is the function that actually does the downloading, by reading the magazine in reverse order. The reason to download specifically in reverse order, is that aside from being executed daily, this function is also executed every time magazine C changes. I add some new link to magazine C, and that new link gets download priority, letting me start doing things with the file quicker, while all the other links are also redownloaded just to be safe. You can achieve this functionality just by using inotifywait</code> directly, but I find a systemd path unit to feel safer / more stable. Put the following in ~/.config/systemd/user/frizz.path</code>: [Path] PathModified=%h/.local/share/magazine/C [Install] WantedBy=paths.target</code></pre> And this in ~/.config/systemd/user/frizz.service</code>: [Unit] StartLimitBurst=0 StartLimitIntervalSec=0 [Service] Type=oneshot ExecStart=env fish -c frizz</code></pre> Then execute systemctl --user enable --now frizz.path</code>, and you should be good to go. </hr> </a> What I like the most about my approach, is that rather than hyperfocusing on raw github links, it simply wants a "link that will be curl</code>ed". What exactly you get from it as a result is a completely different question — basically it's quite satisfyingly flexible. Think of the many programs you've seen whose installer is some form of curl link | sh</code>. You could now instead add that link to magazine C and soon open it in your editor, to confirm the safety of; Then you can manually execute it. As a bonus, you get to autoupdate that installation script, if that's for some reason something you want to do. You can curl straight up files this way, too. If there's some place that you can curl to download some file (that may update over time), that's another usecase for frizz. Truthfully I don't know the extent of this idea, but it sure feels quite powerful! footnotes</a></h1> ^{1 </a> As well as other git remotes I'm sure, I just don't know how.} ^{2 </a> This was truthful at the time I wrote it, but at this point it's a lie :p Now I use a harp} ^{3 </a> to get to the frizz data directory, and I have an abbreviation e.</code> that resolves to helix .</code>, which is somewhat hilariously significantly nicer than having to e .</code>, which was the case before. Crazy how much of a difference really small things can make! (that's what she said)} ^{3 </a> A "mostly travelling"-related concept I came up with and have been dragging along through programs I use a lot. The actual program behind this is}here</a>, but for an actual introduction about what harps can do for you, read the harp section in my helix fork</a>. (TLDR is that you can interactively but permanently alias files and directories, for fastest access time) consider sorting Axlefublr — Thu, 01 May 2025 00:00:00 +0000 I'm almost certain you have a problem that you either don't realize, or don't have a good solution for. Sometimes in code, you need to place many things in some sort of order. And sometimes, there's no one order that is logically significant. An example of this is configuration options. There isn't really an "order" to them, within each section: you are setting all of them. An even more obvious example I have on hand, is a function holding fish script I have, that I use to organize and back up setup processes for various programs: look here</a>. There too, there isn't some particular order to them. Sure, in the initial setup I'll make fish work, then git, then niri, then probably waybar; but aside from those "blocking" setups, that basically act like dependencies for other setups, there is no obvious order — most things simply behave like a set, rather than an array. Something that I started doing some time ago, is explicitly sorting things like this. Now, looking through this set is organized; it will always be obvious where a given thing is, and additionally it will always be obvious where to insert a new thing, without making the file more messy. I memorized the indexes of the letters of the alphabet using anki</a>, to make this type of manual sorting way easier for me. No need to sing the alphabet song every time. But that's just for the manual sorting I do, like in the setup function holder above; usually things that you may consider sorting are single lines, and those you can easily sort with a command or some such, if you use a half decent text editor. However even with that functionality, it can still feel a bit too manual to feel worth it, not gonna lie. This is why I wrote a neat lil program called partialsort.rs</a>! This isn't exactly a promo, as the program is written as a wks script</a> rather than a normal repo-ed rust program that you could install more easily </blockquote> The idea of it, is that I can mark sections of files with [[sort on]]</code> and [[sort off]]</code>. When I run the formatter over the file, the lines between these two markers get sorted! My helix fork</a> then has an integration that allows you to run a global formatter (that can happen to be partialsort.rs) on write. If you use something like neovim, adding a global formatter should, interestingly, be both more and less painful. Another option I used to use, is to run a formatter like that on git commit hook. Regardless of how you may simplify the process of sorting things for you, you will soon find out how much cleaner things become. Especially for various configuration files, which is my main usecase. After writing the config file for the first time, you are likely to be coming back to it again and again, changing, removing, and adding stuff. It gets so much easier and faster to do so, when the items you intend to change are set in an obvious order! :D Consider sorting! change wallpaper on wake Axlefublr — Wed, 30 Apr 2025 00:00:00 +0000 I managed to do something really neat. I wake up at almost random times, and so simply changing my wallpaper every day at 5am will be wonky. Sure, often times that does match up to be before I wake up, but other times it's in the middle of the day for me. change wallpaper</a></h1> First, we start by having a script that will actually do the wallpaper change. swww img -t any --transition-fps 255 --transition-duration 3 (propose.rs wallpaper 70% ~/.local/share/magazine/T)</code></pre> I'm sure you already know what it is for you, assuming that you already set up a wallpaper daemon. If you haven't, I strongly believe swww</code> is just directly the best one (for wayland). "Wtf is propose.rs</a>" you might ask? Ah! It is proof that my idea</a> ended up being not that viable, and so I changed my approach. Irrelevant for this blog post though. catch suspend</a></h1> The next step is to make the suspend handler. I assumed at first I would be able to simply use systemd's existing mechanisms to make my script run After=</code> suspend.target, but the docs specifically mention how that is not a thing. Intead, you put all the scripts you want to run on suspend into /usr/lib/systemd/system-sleep/</code>. Two caveats with this! The scripts run twice: before and after suspend. To differentiate, they are passed either pre</code> or post</code> as the first argument, among other things you can learn about by reading man systemd-sleep</code>. The more annoying to deal with part, is that these scripts are explicitly stated in the docs to not interact with the currently active user graphical session. In simpler words, these scripts should assume that all of your wm, waybar, and significantly wallpaper daemon aren't a thing and won't work, at the time of execution. Notably, this is not an issue of running on root level (which it does), that could be solved by the -u</code> flag of sudo</code>; This is simply a timing issue. This is why we can't just make this script run the wallpaper changing script — it won't work. Instead, we will do it in a very roundabout way. #!/usr/bin/env fish if test $argv[1] = post touch /tmp/cami-just-suspended chown axlefublr:axlefublr /tmp/cami-just-suspended end</code></pre> When the computer wakes up (post</code>), we will creat a file that is both accessible by root and the user. I chown</code> it for good measure, but I'm not sure it's necessary. Next, we create a user-level systemd path unit. A path unit is simply a thingy that watches for filechanges. You could alternatively simply have a script that uses inotifywait</code>, but I find a systemd unit to be more trustworthy. Place this file as ~/.config/systemd/user/wake.path</code> [Path] PathExists=/tmp/cami-just-suspended [Install] WantedBy=paths.target</code></pre> And this file as ~/.config/systemd/user/wake.service</code> [Unit] Requisite=graphical-session.target After=graphical-session.target [Service] Type=oneshot ExecStart=rm /tmp/cami-just-suspended ExecStart=/home/username/r/dot/scripts/wallpaper-change-script.fish</code></pre> To enable this, you'd run systemctl --user enable --now wake.path</code>. Thanks to the --now</code> flag, it will activate immediately. Thanks to the WantedBy</code> in the [Install]</code> section of the path unit configuration, this will autostart on your next boots 👢 Because I'm not sure how soon the suspend handling scripts come into effect, I'd reboot for good measure. But in case you don't need to, test it out! Sleep / suspend the computer, then wake it up. The wallpaper should change! :D If you set this all up, and systemctl --user status wake.service</code> shows an error saying "wallpaper-change-script.fish wasn't found", it is entirely your fault.¹ /j </hr> </a> ¹ I'm making fun of the strawman reader that didn't intuit to change /home/username/r/dot/scripts/wallpaper-change-script.fish</code> to the actual location of their wallpaper changing script. In the case you forgot to chmod the script (or the suspend handling one), that's far more understandable. every row modifiers Axlefublr — Mon, 14 Apr 2025 00:00:00 +0000 An AI hallucinated, and god am I thankful that it did. </hr> </a> I've been trying to find reasons to finally switch to kanata</a>: I've tried it before in the past, and while it was really cool, ultimately it didn't feel worth the effort. But! If I collect enough significant advantages over xremap</a>, I'll be able to power through the magnitudional task of reading through the docs, and processing the very hard concept of how remapping works in kanata. First, my friend amandin</a> swears by homerow mods. I've tried them out before and they didn't work out :c But maybe there's something special about his approach that is only possible in kanata? (spoiler: yes but not his). My magazine</a> implementation is like, 900+ lines of yaml. Hilariously, I want to add even more! But doing this with xremap is just not viable anymore... Maybe kanata has the answer, with all its extra functionality? I was talking with chatgpt, trying to compare xremap to kanata before I decide to embark on this journey. It told me that xremap operates on a higher level than kanata: kanata using evdev, and xremap being on the OS level. For a remapping program, it's better to be lower, so this got me convinced that I should switch to kanata! thank the hallucinaton!</a></h1> Turns out that both xremap and kanata operate on the same level (evdev). Thankfully I realized this only after I finished my switch to kanata: thinking that I'll get a performance benefit (smaller delays) helped me stay motivated :3 Little did I know that I'll be getting myself into larger delays! Because I now use home row mods 🥳 every row mods</a></h1> The basic idea of home row mods, is for you to make a</kbd>, s</kbd>, d</kbd>, f</kbd>, j</kbd>, k</kbd>, l</kbd>, ;</kbd> into tapholdy modifiers. If you just tap the key, it produces the key. If you hold the key, it becomes a modifer like Shift</kbd>. The computer does not (yet) read your mind, so it needs some semantic to figure out what is a tap and what is a hold. Usually tapholdies wait for a timeout, after which the key will act as its hold variation. If you released the key before this timeout elapsed, it will fire the tap variation. So this is pretty interesting! Your muscle memory is strongly used to keys doing their action as soon as you press them, not release them. When you first try home row modifiers, they feel very weird exactly for this reason. But the biggest reason for why people might give up on home row modifiers, is because of the home row part. Some, but not all keys acting only on release feels very confusing and spotty! You can reasonably get used to this behavior if all keys acted the same way, but if only some of them do, it's way too tricky to get comfortable with! So I came up with a 💥ive idea: I will make every single key tapholdy, even if I don't yet have a usecase for the hold behavior. This is just to get consistency across all keys I press (except Enter</kbd> for now, incidentally), while also allowing easier addition of extra behavior onto key holds, without having to retrain my muscle memory every time. an important caveat</a></h1> Having to actively wait for a timeout to elapse to use any modifier doesn't sound like a good value proposition. This is why kanata provides an alternative variant of the usual tap-hold</code> action: tap-hold-release</code>. If you press and release a key while holding a tapholdy, it will automatically be considered as a holdy. This variation is our second thing that makes tapholdies viable! I hate it when waiting is an input; but if I can learn an alternative way to use my keyboard to circumvent it, I'm far more excited about the whole idea! It's fairly difficult to get used to, don't get me wrong, but I assume I'll eventually get very comfortable at making sure to release keys before releasing their respective tapholdy. Here's another variation, that sounds even better, until you actually use it :p tap-hold-press</code> considers a tapholdy to be a holdy if you press another key while holding it. Rather than press and release of the above action, just the press is enough. This makes using modifiers heavenly! But typing normally? Hellish! You don't realize how often you're pressing another key before releasing the first one, until you try to use tap-hold-press</code>. I encourage you to try, though! There's probably a level of typing speed at which this doesn't matter that much, but at mine (~75) it's pretty unbearable. the goodies</a></h1> Now that we've talked about how to make tapholdies viable, let me share how I made them useful for myself! Here's my kanata config.</a> First, I made d</kbd>/k</kbd> to holdy into ctrl</kbd>, s</kbd>/l</kbd> -> shift</kbd>, f</kbd>/j</kbd> -> alt</kbd>, and w</kbd>/o</kbd> -> meta</kbd>. I never need to press shift</kbd> along with meta</kbd>, which allowed me to free up a</kbd>/;</kbd> for other uses, where pressing possibly all modifiers (except meta</kbd>) at once is significant. So now, my tapholdy a</kbd> acts as an arrow keys layer! Along with things like pagedown</kbd>, pageup</kbd>, home</kbd>, end</kbd>, backspace</kbd>, delete</kbd>, tab</kbd>, and even enter</kbd>. Back in xremap, I also had an arrow keys layer similar to this one. However, instead of being a while held layer, it was a toggleable layer, that was much more of a pain to use because even for a single arrow down I'd have to press capslock+f</kbd> twice. But now that I can just hold a</kbd> instead of trying to come up with a modifier for which I have no available key, I can easily use the arrow keys layer as a "while held"! Absolutely stupid hotkeys like discord's ctrl+shift+alt+[down|up]</kbd> and firefox's ctrl+shift+[pgup|pgdn]</kbd> are now not just viable, but easy to press! I value remappability in programs so strongly (and it's part of the reason why I switched to floorp</a>) because I refuse to press the really uncomfortable default hotkeys that plague every program. ctrl+f</kbd>? ctrl+d</kbd>? No thank you. But now they're not a problem! So aside from just making things more comfortable, home row mods also allow me to chill about remapping every program I use to make it viable: since I can press anything easily now, I can just stick with the defaults of most things and not worry about it! Tapholdy ;</kbd> is my numpad layer. Always hated reaching for the number row, so now I have this neat virtual numpad: 1234567890 = fdsrewvcxa Tapholdy /</kbd> leads me to the function key layer (F1-F12), and mimics the number layout of the numpad layer. F11 goes on q, F12 on z. Sue me. e</kbd>, i</kbd> and '</kbd> are layers for the various "global functionality" hotkeys I used to have in xremap. Things that used to be on capslock or the meta key, possibly with extra modifiers, are just a single key away now! I hate the effort it takes to type various symbols, like @*#`&, etc. This is why some time ago in xremap, I made capslock + the right side keys to output all these symbols, placed how I like! The downside is that with a single modifier, I can't exactly place all the special characters on the keys that I'd like, and some of them still need to be on an extra modifier aside from capslock, to fit. This is why I use x</kbd> and c</kbd> as my two symbol layers! Now not only do I get to place all of the symbols onto my preferred keys, but I also get a bunch of unoccupied spaces! That's where the next thing comes in. On linux, you can press ctrl+shift+u</kbd> almost everywhere to insert a unicode symbol by typing in its codepoint. Kanata has an interesting hacky action called unicode</code> that uses this exact mechanism, to allow you to enter unicodes on a whim. To my great surprise, it actually works and does so consistently! So I made use of the free spaces on my symbol layer, to have them unicode</code> other things I commonly use: “”—‼️™ But the concept of the x</kbd> and c</kbd> layers is still, for the most part, for "special characters" rather than emojis. And I use emojis a lot! So that's why I decided to add another layer that is specifically for entering emojis. This layer uses the keys r</kbd> and u</kbd> so that I can comfortably use both sides of my keyboard to assign emoji shortcuts. Here are some of the emojis that are on this layer now: 😭🤯👏✍️🗣️💀🔥🚀🐐←↓↑→😋🥺❌✅ this deserves a section</a></h2> Now onto the final tapholdy, the one that fully wraps me in excitement and awe at my decision to switch to 1. kanata 2. every row modifiers. A layer so good that it can make the entire journey worth it by itself. Meet the venerable 𝕄𝕆𝕌𝕊𝔼 𝕄𝕆𝔻𝔼 (I just went and made a doublestruck letter layer for this, lol) I have tried many times to make mouse mode work, and have attempted multiple very different approaches. All of them ended up being constantly forgotten about, as none of them are truly comfortable to use. Since I have so many free modifiers, and am interested in making full use of kanata, I decided to try making a mouse mode again. I did not expect for it to be this amazing! I hold Space</kbd> to enable the layer, and that's quite important for reasons I'll explain later. h</kbd>, j</kbd>, k</kbd>, l</kbd> move the mouse directionally. For the first 300ms, the moving speed is quite slow. But after that, the mouse moves at a good pace. I found that, for better or worse, it's most natural for me to get "more or less there" with the mouse, and then do microadjustments to actually pinpoint the place I want to click. By starting slow, I can play into this naturality: I can easily tap multiple times to adjust the precise position, but move plentily fast on hold! As I mentioned, usually the mouse mode is something I didn't use in normal operation, but instead only when I felt like being extra. But this I actually feel like using almost always, over the real mouse! Initially I went with the obvious u</kbd>, i</kbd>, o</kbd> for the left, middle, right clicks, but during usage I realized something interesting: moving the mouse with the mouse mode feels so good, that I can actually consider click-dragging over text to select it... Yes really! Holding u</kbd> with one of, or multiple of h</kbd>, j</kbd>, k</kbd>, l</kbd> feels really uncomfortable, as I didn't design with the thought in mind. That's why I put f</kbd> to be left click, d</kbd> to right click, s</kbd> to middle click, and this is also the reason why Space</kbd>, rather than my initial z</kbd>, is the key that enables mouse mode. Sounds perfect at this point, right? Now I can move and then click with no interruption, as well as easily be able to click and drag, with any of the three mouse buttons! But I got another idea: since I'm already supporting click dragging with all three buttons, why wouldn't I also support holding modifiers while clicking? s</kbd>, d</kbd> and f</kbd> would be required for this, so I moved left click onto a</kbd>, right click to ;</kbd>, middle click to '</kbd>. Incidentally, mouse wheel scrolling are ←↑↓→ on m</kbd>, ,</kbd>, .</kbd>, /</kbd> and the back / forward buttons are on [</kbd> / ]</kbd> conclusion</a></h1> It took me around 3 days to get comfortable using this entire system. I might be spotty at some hotkeys here and there, but normal operation feels quite solid already. This sounds like a pretty fast learning curve to me! Not having to cry over horrendous hotkeys, or over keys being too far away to be viable to press, is truly heavenly. If you haven't tried every row mods, and especially if you have and gave up, I encourage you to apply my approaches and tips to make this system viable for yourself too. It's a lifechanger! bye bye firefox Axlefublr — Tue, 08 Apr 2025 00:00:00 +0000 You might reasonably expect me to have switched off from firefox due to the recent privacy concerns drama. But it was me, Dio!</del> But I actually could not care less about my privacy. Matter of fact, I think it's strange and silly to expect your browser to be private about your data. The web is so huge that I can't get how this can ever be an expectation or even a hope. The actual reasons are somewhat muddy, and because of that I couldn't collect enough energy to actually start the switching process: my firefox switch took an ABHORRENT amount of energy, and repeating that again felt quite scary. My partner really loves this browser, and wants me to try it out a lot</li> It allows you to change hotkeys</li> It has built in workspaces</li> Browser level css is "better" (I didn't quite know in which way yet, but trusted it)</li> Because of being able to change hotkeys inside, I offload the need for xremap, as I intend to switch to kanata soon</li> </ol> css</a></h1> The browser level css configuration turned out way better than advertised. Truly stunning! Whatever I try to do just works practically immediately, everything is obvious and straightforward. It took me multiple days to get firefox just right, and yet I'm almost there on floorp after a few measly hours. That's wild! To be fair, there's likely a big bias at play: after cssing firefox, I've gotten a lot better at doing so, and am now judging floorp as if I have the same level of knowledge as I did before cssing firefox — this is not the case and it's likely my knowledge, not the browser that makes it that easy, but still I'm very happy! :D To get started cssing the browser, the process is quite a bit more discoverable. Right click on the workspaces button to enable the menu bar. In it, press CSS -> CSS -> Create Browser CSS file. In the prompt shown to you, you will create a css file that you'll be editing to customize the browser ui. You can then find the file to edit it as you wish, by clicking "Open CSS Folder" in the same menu. Unlike the usual firefox userchrome configuration though, you don't have to restart the browser for the changes to take effect! Just press alt+r</kbd> to reload your css file into floorp whenever you make a change in it. Not having to restart the entire browser to check every change is an incredible help for productivity. Although for other things that I might wanna restart my browser for, there's another built in hotkey to do so: ctrl+alt+r</kbd>. Here is my css file</a>. I thought I might as well share it since I'm talking about it, but I give no guarantees that it will be helpful, well written, documented, or even work for you. workspaces</a></h1> I used sidebery for a single reason: "workspaces". It calls it "panels", but no matter. It implements them via hiding and unhiding tabs as you move through the panels (not by default; it's an option), so you can probably imagine how hacky it feels to use. Hilariously, it's still faster and smoother than workspaces were on vivaldi. Well, floorp has workspaces built in! And they are completely and incredibly smooth! Sidebery requires you to show the sidebar for it to work. Pretty weird ngl, considering that it does allow you to set hotkeys for basically every action. So, I did css to display: none</code> the sidebar, while it still technically was "on" — that allowed me to use the hotkeys as expected. The downside to doing this is that any time I wanted to add a new workspace (panel), I had to dig into my userchrome.css by finding it in firefox browser devtools, remove the line the removed the sidebar to enable it back, add the workspace, and then remove the sidebar again. I don't create workspaces that often thankfully, but yeah it was definitely a pain. In floorp, you simply get a small thingy to the left of your tabs, that shows the icon of the current workspace (as well as its name, optionally) It's tiny by default, so I made it a bit bigger with css. Unfortunately in terms of icons, you have to pick among the predefined ones: you can't blammo an emoji or svg, how I'd love to be able to do. But good enough! A hack you can probably use, and one that I might try out, is to name the workspaces using emojis, and remove the icon with css. That way you'll only see the name of the workspace, which just so happens to be an emoji of your choosing. </hr> </a> Couple of days after writing the above sentence, I did try out the idea. Turns out it's awesome! :D Now I simply name the workspaces with emojis, and get to have a nicer looking indicator than the default selection of icons I'd have to otherwise use. Here's the css to remove the icon: #workspaces-toolbar-button>.toolbarbutton-icon { display: none !important; }</code></pre>hotkeys</a></h1> You can configure your hotkeys! Quite a few of them, at least. Now I get to have alt+h</kbd> / alt+l</kbd> go the previous / next tab, without having to do an xremap hack to achieve that. Your remapping choices aren't even close to the power of something like vivaldi, though. Still, much better than not being able to to begin with, like in base firefox. For example, while you can set hotkeys to go to the previous / next workspace, that's all you get. Yes, somehow there aren't built in actions to move the current tab to the previous / next workspace, or really any other workspace related action you can bind to, which is very strange. I guess I'll give some leeway with the excuse that the project is somewhat new and undercooked. But still, I never get how features this obvious are missed. Even these two actions are kinda buggy. When you go to the previous or next workspace, you toggle the workspaces panel (↓). So say you start on the 🌿 workspace and go to the next workspace (🐛). The workspaces panel is now opened. You continue going next to 🥕 — the panel is now closed. Then onto 👩‍🏭... and it's opened once again??? So as you move through your workspaces, the panel plays peekaboo with you. I'd be fine with it either showing always as you move, or never showing, but somehow it does the worst possible behavior. So far I don't have a good solution to this, but I solved it well enough: I display: none</code> the workspaces panel as a whole, and enable it whenever I need to add, rename, or move a workspace. But wait Terri, didn't you complain about having to do this with sidebery?! :o </blockquote> Yes! But there are reasons why doing practically the same thing in floorp is less of a pain: I can reload my css via a hotkey</li> Doing so does not restart the whole browser</li> I simply edit the css file in helix to then reload, rather than having to change it in browser devtools to avoid a restart (how I needed to in firefox)</li> </ol> Here's the css I use to remove the workspaces panel: #workspacesToolbarButtonPanel { display: none !important; }</code></pre> </hr> </a> Of course, if I really couldn't move tabs across workspaces with my keyboard, I wouldn't've switched to floorp. No way. But a certain feature comes to save me: "Custom actions". This is probably the coolest part of floorp, for an experienced user. You can set hotkeys to execute your arbitrary javascript! :o Go to about:config</code> and search for floorp.custom.shortcutkeysAndActions.customAction1</code>. You set that setting to the javascript you want that action to execute. Then in about:preferences</code> -> Keyboard Shortcuts -> Custom Actions, you can set hotkeys to execute those custom actions. Interestingly you only get five of them. A bit of an arbitrary restriction, but I'd usually expect that arbitrary number to be 10, not 5. I already use 3 of them — a bit quick to run out of. This is also why I don't solve the peekaboo problem with custom actions, even though I technically could. My partner wrote this custom action for me, that moves the current tab to the next workspace: (async () => { const currentTab = window.gBrowser.selectedTab; const workspaces = await gWorkspaces.getAllWorkspacesId(); const current = await gWorkspaces.getCurrentWorkspaceId(); const currentIndex = workspaces.indexOf(current); let destinationIndex = currentIndex + 1; if (destinationIndex >= workspaces.length) { destinationIndex = 0; } const destination = workspaces.at(destinationIndex); await gWorkspaces.changeWorkspace(destination, null, false, true); })();</code></pre> How to make this move the tab to the previous workspace is an exercise for the reader. I believe in you. Another issue I found, that is solved by a custom action: pressing Escape</kbd> while in address bar doesn't focus the page. I'm a vimium c user, so I really don't want to use my mouse to focus the page back after focusing the address bar. Being able to do so with the keyboard is a corely important workflow bit for me! I blammoed document.querySelector("browser[primary='true']").focus()</code> as a custom action and bound it to a hotkey. I'd rather Escape</kbd> work by itself, but this is good enough I think. proxy</a></h1> Let's get to the third thing that would make me give up on the switch, if it wasn't for my partner. Proxying works strangely in firefox for me. The FoxyProxy extension that you may know straight up doesn't work for me there. However, if I configure my proxy in settings of firefox, it does. In floorp, FoxyProxy started working for me 🥳 Except for playing videos on youtube... I used the same exact proxy, and it does continue to work like normal in base firefox, so this was very strange! At first I assumed that it was me changing some setting that fucked things up, but after trying out a blank floorp profile for a test, my proxy didn't work there either. So, my conclusion is that the internals of proxying work differently in floorp, for one reason or another. In a panic, I start considering my options of solving this. I was too deep at this point to want to go back to firefox (workspaces are too good), and opening firefox just for watching youtube felt assy too. Alternative youtube frontend? Trying to make yt-dlp work again? Quitting youtube? /j I was saved once again! I now have an extra proxy that does work for loading youtube videos in floorp (not sure why), so I can continue to use this browser in peace 😌 </hr> </a> Overall, the feeling I get from floorp is that it's a bit undercooked, but gives you the power to cook it to your preference. That is exactly how I approach most software, for better or worse, so that's a green flag for me :3 randomization sucks Axlefublr — Tue, 25 Mar 2025 00:00:00 +0000 You might instantly think that I'm going to be talking about how there's almost no real randomness in computers, and instead mostly pseudo randomization. Interestingly, I have the exact opposite issue: randomization feels too random! Say you want to pick 5 random numbers in a range of 1 to 10. A fairly human sequence is something like this: [7, 5, 1, 8, 3] I simply put in random numbers in the range as they came to my head. Yet look how balanced they are! And no duplicates, too! If you're tasked with picking random numbers like this, you're unlikely to choose duplicates. It simply feels unnatural to do. A computer, however, will have not mental blocks like that. You (unless trolling) are unable to produce the following set: [7, 7, 7, 7, 7]. Computers can (although it is very unlikely). perceived randomization</a></h1> If tasked to distribute points on an area randomly, a human will probably start doing the 3rd option, think "wait I'm being too predictable" and switch to the second option. While in reality, true randomness will look more like the 1st option. We expect randomness to behave in a spread out way, but that's not how it actually works! And it's the reason why normal randomness tends to feel kinda incorrect. shuffle</a></h1> Biggest example of randomization feeling bad is the shuffle button in your music app. It will often feel like it has a preference for some songs, and never plays some others. You start to shuffle some playlist with 100 songs and listen to 20 of them. Then you switch to listen to something else, and come back to the playlist, reshuffling it. You have now broken the shuffle, somewhat. Previously, in a singular shuffle, the music app wouldn't repeat the same songs until you've listened to them all. But because you reshuffled, it picks out of all 100 songs again, and because of true randomization that I pointed out in the above section, it very much might pick a song you listened like 5 minutes ago, rather than picking a song you haven't heard in a while, which would "feel" more random to you. I have around 5000 liked tracks, so this issue becomes very noticeable at scale. This is why I created 50 playlists! Say I added 10 more tracks to liked. The first one will go to playlist 1, the second one to playlist 10, 3 -> 19, 4 -> 28, 5 -> 37, 6 -> 46, 7 -> 5, 8 -> 14, 9 -> 23, 10 -> 32. If I split 5000 tracks into 50 playlists like this, each playlist will have around 100 tracks, and the reshuffling issue ends up being wayyyyy smaller. Also I increment the next playlist by 9 rather than 1, so that none of the playlists have a "theme", or are discernable from one another, and feel correctly random. the point</a></h1> Anyway, this is not what I actually started this blog post for, lol. I got a recent obsession about wallpapers, as I made it so a random wallpaper would be chosen every day. As you'd expect, some wallpapers feel like they're picked all the time, while some others I never see. So I thought: "what if I ensured this could not happen?". My idea is the following: I'll have a cache that remembers how many times each individual option has been picked before. Before picking out of the options, we filter out all the options whose "count" is bigger than the minimum count of all the items. Let's start with an example. We have four options: apple, banana, orange, tomato. All of them start with a count of 0, because none of them were picked yet. We begin the randomization process, and banana was randomly picked. Its count is now 1. We randomize again. We go through all the options and check the counts. We realize that the lowest count any option has is 0 (as every other option hasn't been picked yet), but banana has a count of 1. We filter out banana, and only pick out of apple, orange, tomato. apple - 0 banana - 0 orange - 0 tomato - 0</code></pre> lowest: 0. picking out of: apple banana orange tomato</code></pre> banana. next iteration. apple - 0 banana - 1 orange - 0 tomato - 0</code></pre> lowest: 0. picking out of: apple orange tomato</code></pre> apple. next iteration. apple - 1 banana - 1 orange - 0 tomato - 0</code></pre> lowest: 0. picking out of: orange tomato</code></pre> orange. next iteration. apple - 1 banana - 1 orange - 1 tomato - 0</code></pre> lowest: 0. picking out of: tomato</code></pre> tomato. next iteration. apple - 1 banana - 1 orange - 1 tomato - 1</code></pre> lowest: 1. picking out of: apple banana orange tomato</code></pre> orange. next iteration. apple - 1 banana - 1 orange - 2 tomato - 1</code></pre> lowest: 1. picking out of: apple banana tomato</code></pre> ...etc etc next visual section of the blog post</a></h1> This works so well! Despite being randomization, it guarantees that you will never see a given option more than once in a cycle. If you think about it for a bit though, you will notice that the following is possible for the algorithm to give us: [apple, banana, orange, tomato, tomato, orange, banana, apple] (we made 8 iterations, 2 full cycles) Isn't it kinda annoying? Despite the guarantee within a cycle, nobody is stopping the algorithm from making some items very close or very far from each other between two cycles. So in effect, it can end up being worse, right? Let's compare this to the more obvious approach: caching the last n items. As you randomly pick items, you "write them down". When you pick the next item, if it's in the n recent items, you mark it as invalid and try to pick again. Basically, you won't see something if you saw it just recently. However, what this method lacks, is guarantees about the other items. apple banana orange tomato fresh blues sheriff harmful heating announces</code></pre> Say you check the last 2 items. It is practically impossible, in terms of probability, but there are no guarantees that "harmful", "sheriff", and "heating" won't get picked over and over again, but never "apple" for example. What is just an unlucky coincidence will feel like a preference to your human brain, and hence will feel like "worse" randomization. Even though my algorithm might show me the same thing twice in a row, it guarantees that afterwards, I won't see it for a while, while also guaranteeing I will see all the other wallpapers, with no off-chance "preference" for any of them. When I see a wallpaper I saw just recently, I no longer worry: I know that after this one, I'll get to enjoy my entire collection, and none will be forgotten. This made me take picking wallpapers more seriously, actually! There is no way I just happen to not see a given wallpaper for a while due to random chance, so I filter out which wallpapers I actually want to use more aggressively. Here is the source code</a> for the program that I wrote for this. It is very much a "for myself" thing so I don't intend to publish it in a convenient way; this blog post more so exists to give you ideas to approach randomization differently, and make it work better for yourself. the journey of noise Axlefublr — Thu, 13 Mar 2025 00:00:00 +0000 I'm autistic! Noise affects me more than the average person. I often fantasize about going deaf. After always having laptops, recently I finally got my first pc! Little did I know how LOUD it can be... Let me take you on a journey of how I dealt with the devil that is noise. first impression</a></h1> I plug in the computer and start going through the motions of initial setup. Despite being distracted by my horrendous monitor (and the following two, before I got my 4th one which is great; but that's a separate story), what was even more clear is how LOUD the fans were. Thankfully my partner is goated, and thanks to it I know that a "fan curve" is a concept that exists. You can define the rotation speed for your fans, depending on the current temperature of your cpu. (That is both wrong and inprecise, keep in mind I'm telling the story as I knew things at the time, I now know more). You do this configuration in the BIOS. The place you get into by mashing (usually) the Delete</kbd> key when rebooting. As I was looking through the settings, I got surprised at how many more there were, compared to my laptop! No wonder though: with more replaceable parts that you have in a proper computer, there is also more opportunity to configure them all. But despite the amount of extra settings, I never found the dreamed fan graph. I was only able to find the overall "modes" that also happened to affect fan speeds: Normal, Turbo, or Silent. Picking the Slay the Spire character in my bios didn't help make things quiet, though. Both fans were still overwhelmingly loud, at ~1800 rpm. I removed the exhaust fan, but there isn't that much noise difference between 2 1800rpm fans, and 1 1800rpm fan — it's loud as hell regardless. I know that's it's a "bad idea" or whatever, but what if remove the cpu fan too, and let the heatsink do all the work? I just need it to not overheat for now, so maybe it'll be fine? I do exactly that and then cautiously stare at the cpu temperature while in bios. Sure, the temperature rises, but very slowly! Maybe this will work out? </blockquote> Is what I think, but eventually it gets to 70°C. Nope, this is not viable :c I put my pc to sleep. I can't use it like this, I'll fucking die! I put off the setup process for when I figure this out. oh that exists?</a></h1> There are certain expectations I had of a working computer, and a couple of them were broken. The computer I bought isn't new, but instead made by some cryptomining guy. First I realize that the pc doesn't have wifi! Wtf! I went and bought an Ethernet cable (😭 it's actually called dog8 😭 <- you probably), pathed the snake from the router to my room, and got myself internet. As a result, my internet is now way faster and more consistent than it used to be before, so I'm happy I did that rather than buy a wifi adapter, but I'm still surprised that missing one was a possibility. Similarly, there was no bluetooth adapter. Thankfully my headphones (JBL Tune 750BTNC) can also be wired, so fixing that issue wasn't a rush. Oh and I forgot to mention: the pc didn't come with a power supply plug. Yeah, even something that simple wasn't there. That's why I got a hunch that the fans were shitty as well. I go through fans I could buy to replace the existing ones, and notice an interesting metric: minimum rpm. And then it hit me: my fans' minimum rpm was fucking 1800!!! No wonder they were loud :o Later on I figured out the extra factor of their shittiness: it's not that their minimum rpm is so high, it's that their rpm isn't controllable: they're missing "PWM". PWM is a thingy (don't ask me) that lets your motherboard control the speed of your fans. Since my fans weren't PWM, they couldn't change their speed, and that's why they have the 1800 minimum: it's also their maximum! So I was looking through fans that had a low minimum rpm (I didn't quite get the pwm memo at the time), and noticed that for the most part, 500 was the lowest they went. Now, aside from product availability differences (I'm in russia 😭), I was stupid: I didn't just buy a fan, I bought a whole ass cooler. See, I already have a heat sink on my cpu, and it at least looks very nice and capable. Especially so for my needs, and I imagine the cryptomining guy had higher cooling needs than me. So instead of buying just a fan, I incorrectly searched and found heatsink + fan combos. Anyway, I take just the fan part from the combo, after realizing my mistake, and try to attach it to my heatsink. The heatsink uses these interestingly shaped metal holders that you're supposed to grab onto the fan to hold it in place; my new fan didn't have anything to hold on to, though :c And here we go 😈 In my classic fashion, I decide to do some redneck engineering, and pull out the zip ties 🗣️🔥 Blammoing a ziptie around the fan and heatsink to hold them together turned out to be far more effective than I expected! Now this is starting to look like my setup :D Using just the cpu fan for my entire pc's cooling (aside from gpu's builtin fans) feels assy, but it's something I can at least fix later — if this new fan is sufficient for the cpu cooling, then I'm set to actually use my pc comfortably! comfortably, right?</a></h1> It definitely got quieter! But not exactly silent. I came back to the bios to see 1200rpm. Didn't expect that last 600 to make such a big difference! However, this is still not the 500 minimum I was promised. It definitely seems like a configuration issue 🤔. Remember those bios modes? Normal, Turbo, and Ironclad? Interestingly, despite everything being in Defect mode, Watcher didn't affect the fans as much as it could: fans also have modes of their own! :o After setting the fan mode to Silent too, it got down to 900rpm. Another significant improvement, although not as huge of a jump as 1800 -> 1200. Still, that's no 500! And I'm determined to get it. There is something even more forcing than Ironclad: Manual mode. Aha! This must be my motherboard's way of setting the fan graph! Although, it's not as clear or understandable as your normal fan graph: you don't get a visual representation of how the speed rises, and the wording is confusing, especially to someone who doesn't know how this works prior. For example, in a normal fan graph, you can make your fans not spin at all (!!) before the cpu reaches 40°C, then start spinning them at 500 before 50°C, then linearly increase their speed until 70°C, and then make a steep rise once the temperature reaches more than that. My motherboard doesn't support such fine grained control. Most cryingly, it doesn't allow my fans to have no rpm under a certain temperature :c Sure, now that I have literally just a single fan, I should always have some rpm at least, but in the future when I buy better and more fans, kinda sad to be required to always spin them :c Anyway! The method I have access to is the following: set the maximum temperature, after which the fans spin at maximum speed</li> what is the maximum speed, in that case?</li> set the minimum temperature, before which the fans spin at minimum speed</li> what is the minimum speed?</li> </ol> Initially, it's worded more confusingly and it's never mentioned how the rpm changes between the minimum and maximum temperature. My guess is that it's linear, but I don't actually know. A fan graph would make this clear and configurable. </hr> </a> I have no clue what temperatures are "good". I never had the ability to optimize fan speed, and so I never had a reason to monitor temperatures. The information I've been able to find is that "as long as you're under 90, you're fine!" but that's not very helpful! I won't listen because that sounds like awful advice! Chatgpt told me that 30-50 while idle and 60-70 while under load is a good spot. But first, trusting an ai on this isn't the brightest idea; even if I do, 30-50 is an awfully big range! And what does "under load" mean? Is watching a youtube video considered "load"? I asked a more trustworthy robot about this, and turns out setting minimum temperature to even 60°C is fine! :o That's very good to know, but to be really safe, I put down my minimum temperature to 45°C, and maximum to 60°C, rather than the 30°C minimum I set at first. Maximum speed to 100% — temperature over 60°C should never be reached, and if it is, I'm afraid of it; so a lot of fan noise sometimes is a good deal to help my anxiousness, while having as little as possible fan noise in the general case. I mentioned that my bios doesn't let me completely stop the fans under a certain temperature. This is because even in manual mode, I cannot set the minimum speed to less than 20% — the bios doesn't allow accept the value. So, even under the minimum temperature, the fans will spin at at least 20% capacity. Which suuuuuucks 😩 The fan is audible, and it really shouldn't be when my temperatures are super fine. I got my desired 500rpm, but it turned out it's not ideal... In the same store where I couldn't find fans under 500rpm, my partner was able to! She found 200rpm minimum fans :O I know what my next goal is now 🔥🔥🔥 voiding the warranty</a></h1> After some time I was able to purchase that 200rpm fan, and replaced the previous cpu fan with it. My expectation was to get a completely silent computer, but in reality I only got a marginal benefit. ...How is that possible? You see, gpus tend to come with abhorrently bad fans. They end up producing the majority of the noise, mostly counteracting your otherwise quiet fans. Alright, time for more redneck engineering! But far more scary now! I will remove the plastic container from my gpu, and instead of the fans that come with it, I'll blammo in the previous cpu fan that I have no use for now, by using a zip tie once again. Sounds like a dangerous idea, right? At that point in time, I was monstrously exhausted from constant noise, and if suddenly my computer stopped working, I wouldn't even be that anxious about it. I was really really exhausted with the constant overbearing noise that my computer made, so I was willing to take a bigger risk than usual. I power off, and remove two random wires (I later realized they're connecting to the psu), placing them in a way that would help me remember how to plug them back in. Then, I remove the gpu from its socket. So far so good. The first two screws that were holding the plastic together with the rest of the gpu were very easy to reach, but the other two were positioned "inside", where I couldn't reach them normally. To get to them, I have to unscrew the 4 screws on the bottom of the gpu. I get to doing exactly that and see a small sticker on one of the screws: "unscrewing voids warranty". This is a used computer — I don't have warranty. Reading it still sent chills down my spine. Ack! After removing the plastic, I was expecting to see a 4-pin port for the fan. I did see a port, but it was actually 5-pin! As usual I ask chatgpt on advice, and the tldr is "it's fucky, don't bother". Well shit, how do I cool my gpu now? The cpu fan is connected to the cpu port. What that actually means, is that the hotter my cpu is, the faster the fan will spin. Not being able to use the gpu port removes this flexibility for the gpu cooling. For most of my usage, I can just set the gpu fan to like 700rpm and that'll be fine. But if I open a game, the fan won't react to the much higher load! To add more flexibility (although still wonky of a solution), I'll plug the gpu fan into the cpu fan port. My reasoning is that if the gpu is getting hotter, the cpu probably is too! The cpu fan will start spinning faster, and so will the gpu fan. Hopefully it's going to be good enough? To make sure, I made this loop in fish shell, that would play a soundeffect if the gpu's temperature went to or over 75°C, and then started playing Dishonored to test it. while true test (cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon4/temp1_input) -ge 75000 && paplay ~/m/soundeffects/camera-shutter.oga sleep 10 end</code></pre> Fascinatingly, I never heard the sound effect, in even 30 minutes of playtime! So it seems like this cooling setup is good enough :D but not forever</a></h1> While this works, I feel it would be both dangerous and stupid to leave it be like this till the end of time. After all, the gpu used to have two fans (although smaller), and now I only have one. To make sure that the cooling is good enough, I think it's a good idea to overcool the gpu, so that even in the worst case scenario (only gpu heats up but not cpu) it's not going to overheat. Some time later I bought another 200rpm fan, and replaced the 500 one with it. Just to test! Before I'd eventually add back the 500rpm fan. But I ended up noticing a very interesting effect! For the first time ever, my fans started spinning slower than 500rpm! :o It turns out that the 500rpm fan, because of its minimum, was speeding up the other, 200rpm fans. Also, after removing the 500rpm fan, things got significantly quieter! It turns out that most of the noise was coming from not from the rpm specifically, but from the 500rpm fan being smaller and shitter. I later learnt that the bigger the fan is, the quieter it is while transporting the same volume of air. The smaller fan was both trying harder, and doing a poorer job! I got to confirm that after testing my temperatures again, with only the new bigger fan, and saw that my temperatures were lower! Matter of fact, surprisingly significantly lower! At this point I don't need the previous fan at all! physical equality</a></h1> At the time of me writing this blog post, I do still only have the two 200rpm fans. I plan to buy two more: one exhaust fan, and one intake fan. However, I found something on the software side that let me eliminate the gpu temperature flexibility worry completely. fancontrol</code>. A program you can run as a service, that changes your fans' speeds depending on the temperature. I actually knew about it way at the start of the pc journey, but I couldn't get it to work. And my thought process was that even if I did get it to work, it wouldn't allow me to have no rpm anyway, since in my head it was my motherboard that completely didn't allow that to happen. Thankfully, I was very wrong! But god, was it a spiky path to set it up. Even now, I'm not exactly sure of all the steps I took to make it work, but here are the basic ones (on arch): Install lm_sensors</code> and run sudo sensors-detect</code>. This will allow you to run sensors</code>: a neat program that shows you various information about your system. Here's my output: amdgpu-pci-0100 Adapter: PCI adapter fan1: N/A edge: +39.0°C (crit = +120.0°C, hyst = +90.0°C) coretemp-isa-0000 Adapter: ISA adapter Package id 0: +41.0°C (high = +80.0°C, crit = +100.0°C) Core 0: +39.0°C (high = +80.0°C, crit = +100.0°C) Core 1: +40.0°C (high = +80.0°C, crit = +100.0°C) Core 2: +40.0°C (high = +80.0°C, crit = +100.0°C) Core 3: +37.0°C (high = +80.0°C, crit = +100.0°C) acpitz-acpi-0 Adapter: ACPI interface temp1: +27.8°C temp2: +29.8°C nct6791-isa-0290 Adapter: ISA adapter Vcore: 888.00 mV (min = +0.00 V, max = +1.74 V) in1: 1.03 V (min = +0.00 V, max = +0.00 V) ALARM AVCC: 3.33 V (min = +2.98 V, max = +3.63 V) +3.3V: 3.33 V (min = +2.98 V, max = +3.63 V) in4: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in5: 2.02 V (min = +0.00 V, max = +0.00 V) ALARM in6: 808.00 mV (min = +0.00 V, max = +0.00 V) ALARM 3VSB: 3.41 V (min = +2.98 V, max = +3.63 V) Vbat: 3.28 V (min = +2.70 V, max = +3.63 V) in9: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in10: 224.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 184.00 mV (min = +0.00 V, max = +0.00 V) ALARM in12: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in13: 1.03 V (min = +0.00 V, max = +0.00 V) ALARM in14: 232.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 793 RPM (min = 0 RPM) fan2: 818 RPM (min = 0 RPM) SYSTIN: +8.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor CPUTIN: +37.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +36.5°C sensor = thermistor AUXTIN1: +101.0°C sensor = thermistor AUXTIN2: +99.0°C sensor = thermistor AUXTIN3: +101.0°C sensor = thermistor PECI Agent 0: +37.0°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C PCH_MCH_TEMP: +0.0°C PCH_DIM0_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled</code></pre> Most things are either invalid or useless, but some values are actually of use to us. Under amdgpu-pci-0100</code>, we see that my gpu likes edging, but it's not very hot because of that yet. You probably have a different gpu than me, so you'll likely see a different section name, but should be able to find it pretty easily. I assume it'll have gpu</code> in its name still. coretemp-isa-0000</code> is the temperature of the actual cpu. But according to chatgpt (lol), you're not meant to use that temperature reading for cooling purposes, and should instead consider CPUTIN</code>. Right next to it, we also see fan1</code> and fan2</code>, with their speeds in rpm. sensors</code> is how I did all of my temperature testing throughout this blog post. All the values here are actually read from device (?) files, so if you run sensors -j</code>, you'll be able to find those paths, to be used in your waybar, and more importantly to find out the correct temperature paths for our next step. Now that you have the sensors working, you should run sudo pwmconfig</code>. It moves you through a series of questions to generate the config file that fancontrol</code> will use. Go through it one or maybe even more times, to get familiar with what it can even ask you. Because pwmconfig</code> just generates a config file, it is absolutely safe to fuck up in this step, as we haven't started fancontrol</code> yet, haven't reloaded it to the new generated config, and we're going to manually edit the config after generating it anyway. The main concept of fancontrol, is that you decide which temperature sensor is the controlling one. "The higher the temperature is in x, the faster you should spin the y fan.". And you get to decide all the xes and the yes. As I mentioned above, we can figure out the relevant temperature paths thanks to sensors -j</code>, but how do we figure out which fan is which? That's where the pwmconfig process is handy: while it's testing your fans' pwm-ness, it will speed them up and stop them. Look inside of your case to figure out which fan path refers to which fan. Kinda crude I know, but that's how I figured it out. config</a></h1> After going through the process, you now have a generated config file in /etc/fancontrol</code>. In theory. Yours will look different from mine, as I manually edited it after and we have different paths for everything. But I'll explain the idea of what everything is so that you can feel more comfortable with using pwmconfig and manually editing the config in the future. # Configuration file generated by pwmconfig, changes will be lost INTERVAL=10 DEVPATH=hwmon3=devices/platform/nct6775.656 hwmon4=devices/pci0000:00/0000:00:01.0/0000:01:00.0 DEVNAME=hwmon3=nct6791 hwmon4=amdgpu FCTEMPS=hwmon3/pwm2=hwmon3/temp2_input hwmon3/pwm1=hwmon4/temp1_input FCFANS=hwmon3/pwm2=hwmon3/fan2_input hwmon3/pwm1=hwmon3/fan1_input MINTEMP=hwmon3/pwm2=45 hwmon3/pwm1=45 MAXTEMP=hwmon3/pwm2=70 hwmon3/pwm1=70 MINSTART=hwmon3/pwm2=80 hwmon3/pwm1=100 MINSTOP=hwmon3/pwm2=80 hwmon3/pwm1=100 MINPWM=hwmon3/pwm2=80 hwmon3/pwm1=100</code></pre> I wouldn't touch the first 3 lines. FCTEMPS</code> is the main juice of fancontrol: which pwm controller (and consequently which fans) to speed up in relation to which temperature. I mentioned that fancontrol</code> is what completely solved my cooling wackness: this is because now the gpu fan is plugged into the chassis port, and depends on the temperature of the gpu (hwmon4/temp1_input</code>). Even though the port is absolutely not the gpu's port, I control its speed via the gpu's temperature! Isn't that nice :3 \ FCFANS</code> is which pwm controller controlls which fan. pwmconfig</code> should've configured this correctly; I haven't touched this option myself. If your thingy is lower than MINTEMP</code> in temperature, its correlated fan will spin at MINPWM</code> of speed. If you don't specify MINPWM</code>, it defaults to 0, meaning it completely stops your fans!! :D If your thingy is higher than MAXTEMP</code> in temperature, its correlated fan will spin at MAXPWM</code> of speed, which defaults to 255 (the maximum speed). MINSTART</code> is meant to be the minumum PWM value at which your fans start spinning, and MINSTOP</code> is meant to be the maximum PWM value at which your fans are still NOT spinning. However, fancontrol for some reason will add extra 20 to your specified MINSTART</code> value, for stability I think? Kinda weird. At first I enjoyed the expected setup where the fans don't spin up until a certain temperature at all, and then start ramping up. It was so (comparatively) quiet, in fact, that I decided to change my setup to be "louder"! Having my ear right next to the case makes me hear the fan faintly, when it's spinning at 800rpm. My pc is placed on the floor, hiding behind the right side of my table — in other words, it's impossible for me to hear that level of noise. And that's why I set MINSTART</code>, MINSTOP</code>, MINPWM</code> all to the same values per fan controller: I want the fans to spin at at least 800rpm at their minimum, but ramp up after 45°C. This way, I keep my system at 39°C for the gpu and 37°C for the cpu under normal circumstances, with no noise downside. In the future when I get two extra fans, those temperatures are likely going to be even better! :D Although keep in mind they are already wonderful temperatures. After getting the config to your preferred state, simply systemctl enable --now fancontrol.service</code> and it should work! fancontrol</code> sometimes breaks after reboots and suspending (sleeping), so make yourself an alias to systemctl restart fancontrol.service</code> to fix those cases. Although in my current venture of learning how to use systemd deeper, I might just fix the .service</code> file to do this automatically for me. next enemy</a></h1> With all this configuration and fan minmaxing, fans are officially not a problem anymore 🥳 However, my pc is still too noisy! I never considered it, but now it's actually my PSU that's making the most noise! So, except the two extra fans, my next pc upgrade will definitely be a PSU upgrade. However it's pretty pricy 😬 so that's probably not going to be soon. Aside from that, I've had a constant hum over the course of months; I think my neighbors are cryptomining. I went through quite a lot of struggles in minmaxing that noise as well, which I've omitted here, but you can imagine how it added salt into the already loud scenario. Throughout all this time I've started using earplugs WAY more often, to the point that now I have to minmax how long I use them to not damage my ears. I bought passive noise cancelling headphones to help with that, but they're a bit shit. I bought active noise cancelling headphones as well, but they turned out to be very overwhelming :c and so I returned them. I would love to move, to solve the currently unsolvable problem of my neighbors being shitty :p wayland screen recording Axlefublr — Sun, 16 Feb 2025 00:00:00 +0000 I recently switched to wayland, and now my ffmpeg screen recording script</a> no longer works, as it depends on x11. To my surprise, screen recording on wayland is easier! Thanks to wf-recorder</a>, this is all you need: wf-recorder -Dyf ~/output.mkv</code></pre> -y</code> skips the confirmation check to overwrite the file, -D</code> only grabs more frames if anything changed on the screen, in theory reducing filesize. Pass -a</code> if you wanna record audio. There are also other useful flags: one of them lets you pick a section of the screen to record, using slurp</code>. Now all you need to do to record a video, is run that command, and press ctrl+c</code> on it once you finish recording. Through some magic I'll explain later, I have it on a hotkey as a toggle. However! The #1 place I'll be sending screen recordings to is discord, which has a 10mb size limit without a subscription. This is why I compress the video after, with ffmpeg: wf-recorder -Dyf ~/i/s/original.mkv ffmpeg -y -i ~/i/s/original.mkv \ -an \ -c:v libx264 -preset medium -crf 21 \ -movflags +faststart \ -b:v 3M -maxrate 4.5M -bufsize 6M \ -vf scale=-1:1080 \ ~/iwm/sco/compressed.mp4</code></pre> This greatly reduces the size, while not being that huge of a difference in quality. Take a look! Original, at 19mb: </video> Compressed, at 2.5mb: </video> You probably can tell a difference between the two, but I wouldn't say that it's staggering. The size difference is staggering, though! The compressed version, in this case, is 8 times smaller! Much easier to fit into the tight limits of discord. Thanks to how I wrote it, the original file is kept too! So if I'm not restricted by size, I can choose to send the original. The recording is also automatically copyl</a>ed, letting me immediately ctrl+v</kbd> it wherever I want! :3 </hr> </a> Let's now get into how I made this into a toggle! The fact that you can gracefully stop the recording with ctrl+c</kbd> isn't just some hardcoded hotkey — ctrl+c</kbd> actually sends the SIGINT signal to the running process, and it's that that wf-recorder</code> is actually listening for. Meaning, we can gracefully finish the current recording using: kill -s INT wf-recorder</code></pre> This assumes that you only have one wf-recorder</code> instance running at a time, which I feel is a pretty safe assumption. So I made myself this fish function, that I put on a hotkey in my kanata config</a>: function toggle_screen_record if test -f /tmp/mine/recordilock kill -s INT wf-recorder else screen-record.fish end end</code></pre> And then the screen-record.fish script is: #!/usr/bin/env fish touch /tmp/mine/recordilock wf-recorder -Dyf ~/iwm/sco/original.mp4 ffmpeg -y -i ~/iwm/sco/original.mp4 \ -an \ -c:v libx264 -preset medium -crf 21 \ -movflags +faststart \ -b:v 3M -maxrate 4.5M -bufsize 6M \ ~/iwm/sco/compressed.mp4 rm -f /tmp/mine/recordilock sl.fish ~/iwm/sco/compressed.mp4</code></pre> So, to go over the whole process, from a neutral state: I want to start a recording, so I press my hotkey. The /tmp/mine/recordilock</code> lockfile doesn't exist, so we go into the second branch, starting the screen-record.fish script. The lockfile is created — the next time we press the hotkey, we'll go into the first branch instead of the second one. We start recording, and waiting for SIGINT to be sent to wf-recorder</code>. I finish my recording, so I press the same hotkey again to complete it. This time, since the /tmp/mine/recordilock</code> file exists, we go into the first branch — it sends the SIGINT signal that wf-recorder</code> is waiting for. Now that the wf-recorder</code> process is finished (which takes some time), the initial script can continue execution. It does the compressing with ffmpeg, then deletes the lockfile. We could, if we wanted to, immediately start a new recording now. The copyl</code> that is now called sl.fish</code> because I'm returning half a year after initially writing this blog post ^{1 </a> copies the uri link to the recording into my clipboard, letting me easily paste it into anywhere.} This is a lot better! Than dedicating a terminal window for the recording script, and then manually pressing ctrl+c</kbd> on it to finish it. Doing so is not too bad all things considered, but is a bit too close to the IBS</del> OBS workflow. So now we don't see when the recording starts and ends 🥳... Wait, what? Right! Let's integrate this recording toggle into waybar, so it's actually clear to us when we're recording, when we're compressing, and when we're done. waybar</a></h1> Are you familiar with named pipes? No? They're really convenient for making waybar widgets the text of which you need to modify externally. I'm not gonna explain them in depth, but the relevant manpages are the following: mkfifo.1</code>, fifo.7</code>. Crucially, FIFOs don't operate via writes to disk, despite having filepaths, and are instead in-memory. That makes them quite a bit faster and a lesser hog of our system resources! If we use a normal file, we need (should?) to create some sort of logic to intermittently clear up old data in the file. Or I guess would could blammo it into /tmp</code> and hope that we will always be rebooting before the bloat ever becomes a problem. FIFOs avoid this issue with the semantic that the data is read-once — one side is expected to continuously consume the content, and once it has read something, the data is no longer stored in the fifo. There can be multiple writers, though — so you don't need to create some convoluted writer service or anything 😌 Let's create the fifa with ↓ mkfifo ~/.local/share/mine/waybar-screen-record</code></pre> Conveniently, once you create a fifo, it stays forever — it's not some temporary file you have to set up on every boot or anything. You can of course later delete it like a normal file. Now we create a custom module in waybar ↓ "custom/screen-record": { "exec": "/home/axlefublr/fes/dot/waybar/screen-record.fish", "format": "{}", "hide-empty-text": true },</code></pre> We're using the output of a script as the text of our module/widget. Every new line that is outputted by the script, replaces the text of the widget; a new blank line resets it. The script is just: tail -f ~/.local/share/mine/waybar-screen-record</code></pre> Now all we have to do to update the widget, is to somehow write a line into the ~/.local/share/mine/waybar-screen-record</code> “file”. It's actually not a file 🤓☝️ And yet, we interact with it exactly how we interact with other files: a simple ↓ echo something >~/.local/share/mine/waybar-screen-record</code></pre> Will make our widget display “something”. And ↓ echo >~/.local/share/mine/waybar-screen-record</code></pre> Will clear it. Now let's come back to the toggle function and recording script, to make them interact with our new waybar module :3 function toggle_screen_record if test -f /tmp/mine/recordilock echo killing >~/.local/share/mine/waybar-screen-record kill -s INT wf-recorder else echo starting >~/.local/share/mine/waybar-screen-record screen-record.fish end end</code></pre> In the toggle function, we report sending the kill signal / starting the recording script. By all accounts, the next step after that happens so fast that we are probably never going to see killing</code> / starting</code> in our waybar module, but if anything ever holds up suspiciously long, this can be helpful for debugging. touch /tmp/mine/recordilock echo recording >~/.local/share/mine/waybar-screen-record wf-recorder -Dyf ~/iwm/sco/original.mp4 echo compressing >~/.local/share/mine/waybar-screen-record ffmpeg -y -i ~/iwm/sco/original.mp4 \ -an \ -c:v libx264 -preset medium -crf 21 \ -movflags +faststart \ -b:v 3M -maxrate 4.5M -bufsize 6M \ ~/iwm/sco/compressed.mp4 rm -f /tmp/mine/recordilock echo copying >~/.local/share/mine/waybar-screen-record sl.fish ~/iwm/sco/compressed.mp4 echo >~/.local/share/mine/waybar-screen-record</code></pre> Now it's clear what's currently happening, if anything! After you press the hotkey the second time, you can quickly confirm that the recording did indeed complete, and is now compressing. Once it's in the compressing stage, you basically wait for the waybar module to become empty again — that's the marker that it copyl</code>ed, and is now pasteable 🚀 </video> I can't exactly show you all the steps, but here's my waybar saying “recording”, lol! footnotes</a></h1> ^{1 </a> This whole section of me explaining how to make a toggle hotkey for this is new! Writing this on 2025.08.04 You see, previously (as can be seen in the example recordings above) I had a wack solution that used kitty's send-signal</code> capabilities, that was too hyperspecific to share.} stop picking on files Axlefublr — Sun, 16 Feb 2025 00:00:00 +0000 When using linux, over time you might naturally arrive at hating guis and preferring a more terminal-centric workflow. One thing that always stood out to me as unescapable though, is picking files. Say you wanna send a file on a messenging app, or maybe blammo an image over another one in krita. You will most likely need to open a file picker to pick the file that you want, or a gui file manager that will allow you to drag & drop. Always found it very annoying. In my terminal, I have tooling like zoxide</a>, harp</a>, yazi</a>, fd</code>, rg</code>, and everything else that makes getting to a file a comfortable experience. But when I need to interact with The™ Outside™ World™ (the browser, mostly), now suddenly that tooling is not very helpful. What I do now is copy the filepath in the terminal in one way or another, and then paste it in the file picker that gets opened; this is better but still kinda ass to have to do. Recently my friend</a> showed me something incredible: the uri-list. Executing the following in my shell: echo file:///home/axlefublr/i/e/memes/blackbeard-writing.gif | wl-copy -t text/uri-list</code></pre> Lets me go on discord and just ctrl+v</kbd> the file. I'm fairly certain that this is the mechanic that file managers use for drag and drop functionality, so this solves the need for a gui file manager or a file picker in practically every place 🤯 </hr> </a> First, it makes a lot of sense to make an alias for this. I'm on fish, so the syntax may differ for you: function copyl echo file://(realpath $argv[1]) | wl-copy -t text/uri-list end funcsave copyl >/dev/null</code></pre> Now I can do something like copyl blackbeard-writing.gif</code> while my current working directory is ~/i/e/memes</code>, and that will resolve to the full path that is required, letting me input a file into my clipboard quickly. I don't like typing in paths though, so for the usecase of picking a file I will generally use yazi</code>. I made a mapping that does copyl</code> there, and now the process of sending memes or whatever else is really nice! termfilechooser</a> begone! </hr> </a> A more overcomplicated idea, is that now you can put files on hotkeys. Use something like xremap</a> for hotkeys that put specific files into your clipboard, like above; now you can drive a meme to the ground even faster! This is what you get by learning linux 😎 For this idea to be slightly more viable though, I heavily recommend using harp. Changing your xremap configuration every time you wanna update your image hotkeys is bound to be very annoying. </hr> </a> Also, this is useful for screen recordings. Screenshotting tools generally put the image into your clipboard, so you just paste it directly. A screenvideoing tool can't put the video into your clipboard (?), but you can just make it copyl</code> the file uri, to be practically the same thing as the file being in your clipboard. Very convenient! Now I can make a screen recording and immediately paste it, no need to open a file picker :3 fish shell 4.0.0 Axlefublr — Sat, 25 Jan 2025 00:00:00 +0000 New fish shell major version is coming out! I want to share with you all the changes that caught my attention. Incidentally, this blog is my excuse to read the release notes</a> to begin with c: First of all, fish shell got rewritten from c++ to rust. This is big because it reduces the barrier of entry for contribution and probably makes fish faster. fish_should_add_to_history</code> function lets you decide which commands to add to history or not. --command</code> flag for abbr</code> allows you to make command-specific abbreviations. Basically, you get to make subcommand aliases but with the power of your shell, not having to rely on the program to support aliasing. Take a look at this: if test -n $variable echo success end</code></pre> Previously, if variable</code> is unset (rather than an empty string), fish would error out — test -n</code> expects an argument after. It's the reason why it's good practice to surround the variable with "</code> like "$variable"</code>, so that it resolves to a single argument even if the variable is unset. Now test -n</code> and test -z</code> don't require an argument after, so passing an unset variable is now valid. Interestingly, only those two options. All the other options work as they did before. This feature is not enabled by default, you'd enable it with set -Ua fish_features test-require-arg</code>. bind</code> recognizes more modifier combinations and differentiates more keys, for example it can tell apart Tab</kbd> and ctrl+i</kbd>. Also, a more convenient syntax for specifying the key like ctrl-x</kbd> is now available. Previously you had to use bind -k</code> for that, now you don't have to. Omg, I literally needed this so bad: history append</code> lets you append a command to fish history, without executing it. <?/path/to/file</code> tries reading the file as input; if reading fails for any reason, outputs from /dev/null</code> (which should be an empty string). Basically, a way to say "read this file if you can, but don't fail if you can't". New path basename -E</code> is like doing path change-extension '' (path basename /path/to/file.txt)</code> — /path/to/file.txt</code> gets turned into file</code>. Math --scale-mode</code> now allows you to choose how the output value's decimal points are handled. truncate</code> / round</code> / floor</code> / ceiling</code>. Abbreviations can now expand after command</code>. As in, command ls</code> will expand similar to how just ls</code> would. They now also do after ;</code> and |</code>. But if you put a |</code> right after a command without a space in between, you're a freak. funcsave</code>ing a function indents the body. If there is no second job, fg %2</code> won't activate the latest one, and will instead fail. Depending on your terminal, now shift+enter</kbd> will insert a newline rather than execute the command, and ctrl+backspace</kbd> & ctrl+delete</kbd> works. In vim mode, the cursor will no longer be beyond the end of the line. I kinda got used to my cursor being 2 character after the end of the line at this point, lol. Also, %</code> motion, as well as functions to f</code>/t</code> to the matching bracket. Options can now be fuzzy completed!! So, --fbr</code> -> --foobar</code> will happen, if there's no better match. When you complete something that has characters that need to be escaped, previously each character would be escaped. Now the completed token uses quotes. Say you are completing a directory named my directory</code>. Previously, it would turn into my\ directory</code>, now it will turn into 'my directory'</code>. </hr> </a> I opened the release notes, saw the ridiculously small scrollbar, and got terrified like "HOW HUGE IS THIS UPDATE??", but turns out the page is so long because it contains all the release notes. So yeah, everything listed above are the neat changes that I found the most significant for myself. Keep in mind though, I might've skipped some that aren't important to me but might be important for you! finally, a good pager Axlefublr — Sat, 11 Jan 2025 00:00:00 +0000 Some time ago, I tried looking for a pager, and found... nothing? How are we content with less</code>? bat</code></a> comes up a lot, but it still uses less under the hood as far as I know. It gives you syntax highlighting, which is nice, but that's the last nice thing about bat that I encountered. That syntax highlighting? Automatically uses a custom theme, instead of trying to use your terminal theme. Blammoes a big ass header for the filepath that you opened, and takes up like 4 columns for the line numbers. "You can change that though" is not really a point: if a program has defaults like these, it's clear it's not doing what I want from a pager. I want more functional bells and whistles, rather than visual ones. And today, I finally came across a pager that satisfies me. ov</a></h1> ov</code></a> is my new favorite puppy. It introduces a few cool concepts that make it sometimes better than your editor! (For viewing files) headers</a></h2> Headers are basically "sticky lines", that are fixed at the top and shown always, as you scroll through. Very useful for programs with columnar output that display the column names at the top, for example! lsblk | ov --column-width --column-rainbow -H 1</code></pre> Well, if you have enough output from lsblk</code> to fill more than a screen, I think you're cooked 💀. But you get the idea: -H n</code> to set n</code> first lines to always display at the top. columns</a></h2> In the above screenshot, each column in the output of lsblk</code> is colored thanks to the --column-rainbow</code> flag. ov</code> has the concept of columns quite engrained into its functionality. You can decide how to split into columns based on width or a delimiter character (/ regex). Even nicer than that, you can align input into columns even if it is not aligned in the source. Say I have this file: apple orange potato hi hello why I hate kitty</code></pre> As you can see, it has three columns, but they aren't aligned. Let's use the --align</code> flag to fix that! ov --column-delimiter ' ' --align --column-mode file.txt</code></pre> However, here's an interesting behavior: ov --column-delimiter ' ' --align --column-mode --column-rainbow file.txt</code></pre> It seems that if your delimiter (a space) is the same as the aligning character (a space), --column-rainbow</code> doesn't work how you'd expect. Oh well. sections</a></h2> Sections are what excites me most about ov</code>. Basically, you can specify a regex that defines where to split the input / file at; you can then press ^</kbd> / Space</kbd> to navigate to the previous / next section. ov jj.toml --section-delimiter '^\['</code></pre> So using sections, you have a nice semantic way to jump between important parts of a file! An example of where that is going to be most useful to you, is for diffs. You simply define something like ^diff</code> and blammo, you can jump across the diffs of multiple files in a very easy way. About that "very easy way" though. Yes, it's genuinely ^</kbd> and Space</kbd> by default. Unfortunately, ov has a habit of having ass / unexpected default mappings. For example, j</kbd> and k</kbd> don't work. Yes really! And that default section header color is quite not readable; I don't see what white you need to use for it to be readable. However, a good habit that ov has, is that you can configure everything! You can configure the colors that it uses (for example, the --column-rainbow</code> colors are those that I set myself), and the hotkeys. So, I'll definitely spend some time reworking like, all of them, lol. However, if you like less</code> mappings (or just can't bother), you can copy a config they suggest in the readme, that mimics less</code> mappings closer. filtering</a></h2> As you would expect, you can search with /</kbd> and ?</kbd>. But that's a given and not very interesting. What I find to be more interesting, is filtering. Using the --filter</code> flag, you can make ov</code> display only the lines that match a pattern; with --non-match-filter</code> — display only the lines that don't match a pattern. Essentially, you get rg</code> for free! Why not use rg</code> directly you may ask? Because you can also filter interactively. Although the default mappings are strange as hell, there is a default mapping for basically every flag! Setting column mode, column mode by width, rainbow, delimiter, filtering and opposite filtering, searching (can be done with a flag btw), headers, sections, section headers, ... Basically, in ov</code>, if you can do something with a flag, you can generally also do it with a mapping. And vice versa. Very nice design! output on exit</a></h2> With something like less</code>, you view some output in a pager, and then never see it again ✨ To look at the output again, you need to re-execute the command that you piped into less. ov -X</code> will do something really neat: show the output in the pager, but also print it to stdout. So once you close ov</code>, the output you were paging will get printed, letting you look at it while continuing to execute other commands. You don't need to always -X</code> though: use the IsWriteOriginal</code> config option to set it to true, if you want. And you guessed it! You can also do this with a hotkey (shift+q</kbd>)! Yes, really! don't even page</a></h2> Similar to less</code>, you can use the -F</code> flag to not even open ov</code> if the entire output fits on the screen. QuitSmall</code> is the config option to set if it's the behavior you always want. tailing</a></h2> You can use the -f</code> flag to follow a file, similar to tail -f</code>. When it gets interesting, is that you can follow multiple files at once using the -A</code> flag. Rather than creating panes for each file (which I'd find annoying), it continuously switches to the file that got updated the most recently. So for example, you decide to ov -A</code> 3 log files; new line appears in log 3 -> you get switched to look at it immediately. Then, log 1 gets a new line -> you get switched to log 1 now. Honestly a very neat solution that I like quite a lot. But if you don't, just keep using the -f</code> flag and use [</kbd> / ]</kbd> to switch between the multiple files. The behavior of -A</code> is so exciting to me: I finally have a good way to track log files :D I just specify a bunch of log files, and then can look at them all in realtime. Better yet, ov</code> supports suspending, so this works well in my suspend-based workflow</a>. word coloring</a></h2> Especially in logs, it is common that coloring some words like ERROR</code> and such is very helpful. Use the -M</code> option to specify a ,</code> delimited list of regex expressions that define what to color differently. pueue status | ov --wrap=false -M 'Killed,Running,Queued,Success'</code></pre> You also can use the -e</code> option to execute the command from ov. ov --wrap=false -M 'Killed,Running,Queued,Success' -e pueue</code></pre> This way, you retain the colors that your command produces, and maybe add some more with -M</code>. Alternatively, you can use unbuffer</code> to trick the program into thinking it's writing to a terminal, to retain its colors. unbuffer pueue | ov --wrap=false -M 'Killed,Running,Queued,Success'</code></pre> "Oh I sure do wonder where to install this useful-sounding program" — no clue, sorry. It's somewhere. check it out!</a></h1> My goal isn't to teach you the entirety of ov</code>, but to sell you on it. Go check out the project's readme</a> to learn about it more deeply! I love how it's written: generally I get super overwhelmed when discovering a program of a certain bigness, but ov's readme is structured in a pretty nice way where I was able to learn it effectively! P.S.</a></h1> ov has an interesting bug I experienced: sometimes, for some of my configured hotkeys (it's random, and doesn't apply to all of them at once), they stop getting recognized and get defaulted back to ov's defaults. So, for example, I set j</kbd> to go a line down; it sometimes happens that pressing j</kbd> will go back to its default function, despite me disabling that in my configuration. So if you're experiencing the same bug as me, build my fork of ov</a> from source. All I do in it, is remove all default mappings, so that your configured mappings are guaranteed to work. how to anki Axlefublr — Tue, 07 Jan 2025 00:00:00 +0000 Anki is honestly a very hard to approach program. If you feel like it isn't, you're using it wrong /hj In this post, I'm assuming that you already want anki and know why you want anki, so I won't be inspiring you; just sharing what I think is the optimal way to use anki. In the next few sections related to settings, here's what you can expect: If I don't mention a setting, it's either insignificant or personal choice; you should check it out for yourself regardless. It's also possible you're reading this in the future, where a new setting appeared that I don't go over (my anki version is 24.06.3). Settings that I strongly recommend a certain value of are going to be marked by ❗ Settings that I VERY STRONGLY beg you to set to a certain value will be marked by ‼️ I'll be expecting you to have already installed anki; the pc version (which desktop os you have shouldn't matter, though). An extra resource along with this blog post that I can recommend, is this youtube video</a>. Global settings</a></h1> Let's go to global settings by pressing ctrl+p</kbd>. Review</a></h2> Next day starts at</a></h3> The rule for the best time is to make sure it's impossible for you to see the next day's cards in the previous day, basically. My default is 5 am. Learn ahead limit</a></h3> 0 This setting is very weird. TLDR: don't use it, but if you're still interested, continue reading this section </blockquote> Imagine you have a bunch of reviews (green (mature) cards) left to do in the deck; when you press “Again”, you see the card in 20 minutes. As you go through your reviews, you might take so long so that you see the “Again” card in the same review session. Usually you're supposed to set learning steps</a> to a high enough value where that won't happen. So, you go through all of your reviews, and there are 10 more minutes until you see that “Again” card. There is nothing left for you to review; you can leave. What “Learn ahead limit” lets you do, is cut down those 10 (or however many) minutes down to zero. It starts acting once you finished all reviews. This is different from the default behavior of learning cards (red ones): those usually can appear whenever in your review session, not just after all other ones are finished. “How is this useful?” you may ask; and my answer is exactly. It is somewhat useless in my experience. Show remaining card count</a></h3> Should be set to true Because it's helpful to see whether you are currently on a new / learning / mature card. Show next review time above answer buttons</a></h3> I had this set to true for the longest time, but recently I disabled it! If you see that pressing “Easy” will make you see the card in 2 years rather than 1.5 years, you will be less likely to actually press it, even if it's the correct decision. Similar case for “Hard”. If you never see the time periods, you make answering decisions that are less biased. Spacebar (or enter) also answers card</a></h3> yep. Set yourself some answer keys as well. Anki is more keyboard-supporting than you'd think! A bit of keyboard navigation</a></h1> We are now done in global settings. To discover a bit of the keyboard navigation support anki provides, let's move onto creating and configuring a deck. There's a Default deck by ...uhhhhhm... default.. Let's configure that one! You could press on the cog with the mouse, but I'll teach you to do that with your keyboard. You can press /</kbd> to search for a deck to study. In this menu, you can press ctrl+n</kbd> to create a new one (don't do it yet). Currently you only have Default</code> so you could just press enter</kbd> immediately to pick it. This moves you into the screen of your deck. No clue what it's actually called, I'll be calling it "yipee screen" from now on. Because after you finish your cards, it says “Congratulations!” :3 In this screen, if you had any reviews to do, you would be able to press s</kbd> to start the reviews. But that's for later; you don't have any cards yet. If you wanted to go back to the main screen of anki, you can press d</kbd>. You might be quick to now search for Default</code> using /</kbd> again, but there's no need: the Default</code> deck is already selected. It's going to be more obvious once you have more decks (if there is even a need), but there's a semantic of "the selected deck" in anki. You can press s</kbd> to jump into the yipee screen of your selected deck. s</kbd> then d</kbd> then s</kbd> then d</kbd> then s</kbd>... Alrightie now from the yipee screen we can press o</kbd> to open the deck's settings. Deck settings</a></h1> I'll warn you immediately: if you press Escape</kbd> from this point, it just discards your changes. You specifically need to press “Save” to save your deck's settings. Daily limits</a></h2> New cards/day</a></h3> You might be quick to set this to a pretty high value. You are motivated and excited about anki, you're even reading a blog about it! You might've even watched a whole ass hour long youtube video about it. “Surely I can set it to like 50, right?” WRONG. You have no idea just how strongly seemingly small effort compiles. You may be absolutely fine with 50 new cards one day, maybe even a whole week, but you're not using anki for a week's worth of memory, are you? Anki is made and designed to be very longform. "Your entire life" type deal. If you rush to set your new cards to some big amount, there's a good chance you'll burn out in like a month and maybe skip a day or two, then come back to 500 reviews and fully quit. Anki is minmaxed with the assumption that you will always be doing your daily reviews. Maximize for that as well. For consistency, not burst. I consider 30 new cards per day huge, but it super depends on the content and the time and effort you're willing to spend. I use anki for: morse code</li> hiragana</li> katakana</li> all country flags</li> all country locations on a map</li> programming languages</li> APIs</li> hotkeys; global ones and those local to specific programs</li> ascii decimal and hex codes</li> alphabet indexes (d = 4 for example)</li> I shit you not, my credit card information. Don't do this, anki isn't meant to securely store your credit card information, lol.</li> </ol> I, on average, spend 20 minutes per day on reviews, with ~11 new cards per day. This is quite small workload all things considered, but the massive benefit I get is that I'm excited about doing anki every day, and it's practically impossible for me to burn out on it. So for the recommendation: you won't really know how many is too many, as it's likely you want to use anki for a different type of information than me, so set it to a reasonable amount (like 10), and feel free to change it as you continue to use anki. If you ever notice yourself feel burnt out with anki, the thing you should configure is the amount of daily new cards. Maximum reviews/day</a></h3> ‼️9999 Out of every single setting in anki, this one is my strongest recommendation. Hell, this is not even a recommendation — I beg you to set it to 9999 and never even consider touching it. If you ever actually get to 9999 daily reviews, you're fucked because you didn't listen to my advice about new cards per day above; the reason to set this setting to such a high amount is mostly semantic. Anki's algorithm is written in such a way where it's most efficient when it's allowed to give you cards at the precise intervals it has calculated. If it's arbitrarily restricted by a cap of reviews, it's simply going to spend more of your time and energy. New cards</a></h2> Learning steps</a></h3> Because of FSRS (we'll get to it), this should only ever be a single step. When you press “Again” on a card, this is the time after which you'll see it. I have it set to 2h</code>, you may choose 30m</code> or whatever else makes the most sense for your content. ❗Do not set multiple steps, just one. Insertion order</a></h3> Sequential (oldest cards first). Lapses</a></h2> Relearning steps</a></h3> Same as above</a>, but for mature cards. Leech threshold</a></h3> At least 3, but then it depends. Personally I use 5. The concept of leeching is made so that you can notice which cards you keep pressing “Again” on repeatedly. So, once you press “Again” on the same card n times in a row, it gets the leech</code> tag. This by itself does absolutely nothing: it's up to you to decide what to do with that information. It's your wakeup call basically, that "hey! this card is really difficult! try coming up with a mnemonic for it maybe?". Once one of my cards becomes a leech, I take some extra time to really burn it into my brain, and press ctrl+alt+n</kbd> to reset it back into a new card, so that I can relearn it again, without the ease factor being fucked up. With FSRS, it's probably a bad idea to reset it like that, so I don't necessarily recommend it. Just, make sure to pay extra attention to the card. Leech action</a></h3> ‼️Tag only. I don't get why “Suspend card” is even an option. “If the card is too hard, stop learning it” — ?????????? wtf Display order</a></h2> Here most things can work well; it depends on what you actually want. So for the most part you should click on each option title to read what it means in the built-in docs. New card gather order</a></h3> Say you have overall 100 new cards; cards you have not yet reviewed. You "take in" 10 new cards per day. This setting decides which 10 cards to pick out of the 100. The 2 values you should consider is “Ascending position” and “Random cards”. The former makes it so you go through new cards in the order that you added them (oldest first). The latter just gives you random ones. Both are good, I just want to say that “Ascending position” is better than you expect. I personally use it. New card sort order</a></h3> Sorts those 10 new cards you got after gathering them. Unless you've made a bad decision and there are 100 of them, this option doesn't really matter. New/review order</a></h3> When you have both new (blue) and not new (red and green (learning and mature)) cards to review, which to show first. “Show before reviews” ensures that you always take in all the new cards first, and then all the reviews. I use it, but I don't recommend it — it's a risky choice. It is better to force yourself to go through all reviews first, before new cards (with “Show after reviews”). However, if you are sure you will complete all of your reviews, starting with the new cards is very exciting! “Mix with reviews” is quite reasonable. Start with it if you're not sure yet. Interday learning/review order</a></h3> Show before reviews. Review sort order</a></h3> There's quite a lot of options here, here are those that I would recommend: Descending difficulty</li> Random</li> </ol> Yep, just two! :3 Burying</a></h2> Enable everything. FSRS</a></h2> Now the JUICE of the settings!! Or rather, of anki itself! FSRS! This is the cool new algorithm that you should be using! Enable it. Desired retention</a></h3> Don't touch it for now. Come back in at least a month. I am serious. If you read the following before having done anki for at least a month, you instantly die: you may increase or even decrease this depending on how strongly (or weakly) you want this deck to be remembered. Alright, the 10% of readers who survived, let's continue! You should click the “Optimize” button once every ~1-3 months, per deck. Don't forget to save right after, too! ‼️Do NOT press “Reschedule cards on change”. You may be excited to put in some extra work to make sure your cards have the perfect periods, but the tradeoff ends up making things worse. There's a good chance you will instantly get a bunch of extra reviews at once, which you may not be able to do all at once. So their "perfect periods" won't even be perfect. But that's misleading too: you shouldn't do them all at once. Because if one day has a bunch of reviews at once, that will repeat on another day some time later. Your reviews that got naturally padded out throughout the days to be balanced, will no longer be balanced. So pressing “Reschedule cards on change” puts you between a rock and a hard place, it's simply not worth it. It's been more than 2 months after I pressed Reschedule, I'm still eating shit to this day. Don't repeat my mistake. Advanced</a></h2> Maximum interval</a></h3> ‼️DON'T set it to a reasonable value. I have it set to 100 years (36500). Trust the anki algorithm. Deck meta</a></h1> We're done configuring the deck! You decided to start using anki, most likely, because you already have one or multiple things that you want to learn. It is natural now to create a deck per each subject that you want to learn. I've been using anki for around two years, and I found that anki decks have actually quite poor UX. Let's pick a list of subjects out of those that I personally learn, and split them into decks. morse code</li> ascii characters' decimal codes (from a space to ~</code>, which is from index 32 to index 126)</li> all countries on a map</li> all country flags</li> useful flags of terminal programs</li> the standard library of the programming language rust</li> </ol> Deck splitting</a></h2> The obvious solution here is to create 6 decks. I only have 2. Morse code is around 50 cards, ascii characters is 94, both country flags and map locations are around 250. What unites all of them is that they're finite. You will eventually go through all of those cards; you won't be adding more. After a while, you'll need to review them less and less. The decks of each one of them will become a “dead deck”: a deck with only a few reviews to do, if any, that you still have to check, travel to, open, review, and go back from. Anki can take a lot of energy, and if you grow to say, 13 decks (I used to have around that many), you will be spending a lot of extra effort on just moving around. A lot of times, you don't just review the mature cards — you'll fail some of them, and have to come back to re-review them. That is a lot of travel time! Decks as organisation</a></h2> You may think that this is an okay tradeoff for the organisation that decks provide. But actually, decks are shit at organisation. I'll expand on the solution in the note types</a> section, but for now I'll elaborate on why decks are bad at organisation. Morse code and ascii indexes. How would you structure the question->answer in those? What I find to be most effective is just the symbol as the question, and just the sequence / number as the answer. This way, I don't spend extra energy on parsing useless words like "what is the x character in morse code?", and instead just focus on the question at hand. Getting to the core, the meat of the question, without all the extra fluff, that really piles up, believe it or not! I'll expand on card creation in this upcoming section</a>, but for now let's stop at the idea that cards should be very minimal. </hr> </a> Great! We put ascii cards into the “Ascii” deck and morse cards into the “Morse” deck. As you go through your thirteen billion decks, you will find yourself confused. You open your morse code deck to do the measly two reviews, and in the rush of answering cards, seeing x</code>, you answer 120</code>, rather than —・・— This happens because anki does not display the title of the current deck you're studying. There is no looming context for you to be able to check back with, and so you'll find yourself answering the wrong question a lot of the times. You answered correctly, but to the wrong question. What do you do in this situation? You eat sand. You have to introduce context somehow, to not confuse cards with similarly-sounding questions. And this is why the first jump is the "What is x in morse code" shenanigans. Decks don't solve organisation, so believe it or not, I'll recommend putting both ascii and morse code into a single deck. We will solve the confusion in the [note types] section. When should you deck?</a></h2> There are only a couple of benefits to creating a new deck. If you don't meet any of them, I don't recommend creating a new deck. News splitting</a></h3> We just added, like, 500 or so new cards. These are long-term — you aren't meant to intake them all at once. So, we need to come up with a scheme to split those new cards per day in a reasonable fashion. Say you added morse code first, then ascii indexes, then flags, then map locations. Depending on your new card gather order</a>, you may either go through all of them in order, or through all of them randomly. If that's exactly what you want, blammo them all into a single deck, unless the next sections on decking positives apply. But let's say you want to be learning three categories at once, rather than trying to rush a single category / randomly picking cards from all four categories. You feel you have 3 new cards per day in you¹, and you want 1 of them to always be morse, and 2 of them to be random selections from the country flag + map location "pool". ¹ pure example, I don't actually think this is viable for the categories at hand </blockquote> To express something like this, you need to split into two decks. </hr> </a> If you were okay with just doing the categories in order, with all 3 new cards being for the same category, you wouldn't need two decks! The “Reposition” action in the card browser (ctrl+shift+s</kbd>) would allow you to put all the categories' cards in the order that you want, even if you created them all in the wrong order¹. ¹ technically speaking you can avoid having to create another deck using the Reposition action by manually positioning each and every card, but this is herculean effort compared to just creating a new deck, and then moving its cards into another deck, once you go through all of the new cards </blockquote> But in our case, we create a deck for Morse¹ code: it will give you 1 new card per day; And a Country¹ deck that will hold country flags and country locations. Its new card gather order</a> setting will be random. This way, you guarantee 1 new card of morse per day, and 2 "country-related" cards per day, totalling three. All this without touching the ascii indexes for now — you'll get to them once you fully learn one of the three categories. ¹ names are arbitrary, choose whatever you wish </blockquote> Ordering</a></h3> We touched on the new card gather order</a> setting — it's quite an important one! For some type of cards, it makes the most sense to learn them in random order. By "fuzzing" them like this, you avoid the issue of one card half-answering the question of the next one. For others, where that half-answering issue doesn't arise, it is best to go with sequential. If you keep adding cards while being served them randomly, you'll end up having "unlearned spots" — some cards will slip through the cracks of how randomisation inherently works, and you might take too long to get to some crucial information to learn. If you learn sequentially, you ensure that you finish a given subject before going onto the next one. Optimization</a></h3> FSRS optimization happens per deck. More precisely, per deck preset. It does its magic depending on how you answer the cards in the given deck. I don't know exactly how it works, but the main idea is this: vastly different subjects will be optimized differently. Both morse code and ascii indexes are fairly similar categories, that I'd argue are very similarly difficult to memorize and to remember. Splitting them up into two decks just for the optimization I don't think is worthwhile — you will likely respond very similarly to both, and so they could just be kept in a single deck, optimized together. FSRS optimization makes it so you see the cards at the correcter time periods, to achieve your desired retention rate. When the information is similar enough, you'll lose far more time, effort, and motivation by switching a billion decks, than you would gain from slightly correcter periods. After switching to FSRS, for four months I didn't even know I could "optimize parameters" in FSRS, much less that I should be doing it monthly. And yet, I was perfectly happy with how anki was working for me. So genuinely don't worry too much about this. To be fair, what counts as "similar enough" is very personal, I don't know if a hard rule could be worded to help you decide. So it's not unreasonable to start with making more decks than needed, and later on merging some (if not all) together, once you get a feel for anki. That's it!</a></h3> Not many reasons to make extra decks, as you can see. I hope you can keep these in mind to help you not fall into the "trap" of the supposed deck meta, winning you time, and saving you effort. Now to the really fun part >:3c Note Types</a></h1> You know that gif with Tony Stark dramatically hitting a helmet with a hammer? This is me with note types. I have tried multiple approaches in using them the most effectively, and found one I believe to be perfect. Let's start with the basics. Default note types</a></h2> In the main screen, press ctrl+shift+n</kbd> to go to the list of default note types. Basic</li> Basic (and reversed card)</li> Basic (optional reversed card)</li> Basic (type in the answer)</li> Cloze</li> Image occlusion</li> </ol> Some of them are quite a mouthful. I'll refer to them as this: Basic</li> Double basic</li> Basic?</li> Type</li> Cloze</li> Image occlusion</li> </ol> If you want, you can even rename them! Note types are going to be something you'll keep on selecting, so having them be unique and easily typable / searchable is very helpful. My “Basic” is just d</code>, and “Cloze” is just h</code>. The default note types showcase what anki even allows you to do in the first place, in terms of question->answer organization. A note type is a template, a constructor: you define how one creates cards. You review cards created using notes. A single note can (in theory) create an infinite amount of cards. Basic</a></h3> Is the most basic note type: it creates a single card. Double basic</a></h3> Is like the above one, but here the magic starts: it creates a card for question->answer AND for answer->question. It is a note type that creates TWO cards, one for each "direction". Basic?</a></h3> You can probably guess now that you can use “Basic?” to optionally create the answer->question card, while it doesn't do so by default. Type</a></h3> Lets you type in the answer, rather than just recalling it in your head. Cloze</a></h3> Omits some part, or multiple parts of the question, and you need to mentally fill in that missing part, to answer the question. Image occlusion</a></h3> Hides some part of an image, that you need to mentally flll in. In other words, it's “Cloze”, but for images. Creating your own</a></h2> Defaults are made to be configured away, so let's discover how you can create your own note types. In the ctrl+shift+n</kbd> screen, click on Basic and then Fields. Fields</a></h3> A field is an inputbox, the text of which is used in some way in the note type. Here in Basic, you have 2: Front and Back. You can add as many extra fields as you want (at least I don't know of a limit), however they won't do anything by default. We'll get to how to make their text appear in your card later. For now, know that you can add multiple fields to a given note (including your own ones we'll create later), and have them appear in the card in different ways. Anki supports html: when adding a card, you can press ctrl+shift+x</kbd> to toggle the html editor. But if you always want to edit a given field as html, here in the Fields view you can set the option below to make the field “Use HTML editor by default”. On a non-html field, the ctrl+shift+x</kbd> hotkey then toggles on the non-html editor. Go back to the previous screen by pressing escape</kbd> and then click on “Cards”. Cards</a></h3> This screen has been confusing for a while to me. So if it feels intimidating, don't worry — it is. The source of this intimidation for me is a couple of buttons and popups that we'll get to at the end of this section, for now let's explore the more obvious parts. Note types are templates that decide how to create cards. Each note type can create as many cards as you want it to. Although by default, a note type creates just one card. Front Template</a></h4> On the left side, you can see an edit field, with three radio buttons above. Here, you define the html template for the cards to be creates with this note type. The main juice that actually makes note types useful at all, is {{Front}}</code>. {{Front}}</code> is a template (that I'll be calling a shortcode) that is replaced with the resulting html that you put in a field. Notice the name: Front</code>. This is a name of one of the fields of this note type. In the previous section, I mentioned that fields aren't used automatically. We get to decide where and how they show up, by putting them in explicitly. Say we created a field called Extra</code>. We can now add {{Extra}}</code> somewhere in the template for the note type, and the text (resulting html) that we put in this Extra</code> field is going to show up there! Back Template</a></h4> Now, click on the radio button “Back Template”. The html is a bit different now! The real semantic of the first and second templates is the following: This is how the card looks when I'm presented the question, and haven't yet answered the card.</li> This is how the card looks when I answered the question, and pressed space to see the answer.</li> </ol> By default, the Front side of the card is also included in the Back side, using the special shortcode {{FrontSide}}</code>. It takes the entire Front side html, and blammoes it in the Back side template. There's nothing stopping you from removing it, though. You can simply remove it from the Back side template, and you won't see the front of the card after pressing space. I don't recommend doing so; you would be shooting yourself in the foot for no benefit. However I hope that showcases that templating is not that magical! How anki shows itself to you is defined clearly, and is changeable by you. Styling</a></h4> Probably more changeable than you expect! The third radio button is my favorite one: you get to define the CSS of your note type! Yes, you can make it look however you wish! I used this to change the fonts used, the colors, and added inline and blockwise codeblocks. You might reasonably ask how you can “Inspect Element” anki to figure out how to css it correctly. There is some plugin for it, and likely some people in the forums have figured out most things. However, I just guessed my way throgh most of it, so I won't give precise advice that I don't have checked. With styling selectors you need, you're on your own. Card Type</a></h4> Let's look at the popup that scared me at first. Well, even now I never touch it (I'll explain why later) At the top, you can see “Card Type” with something like 1: Card 1: Front -> Back</code> Let's process that. A note type can create any number of cards. That is what the 1:</code> stands for. Which one? I have no clue. At least one of them, lol. The other one of them stands for god knows what. So, 1: Card 1: Front -> Back</code> means: out of potentially many, this is the first card that's created by this note type. In this specific card, the Front side is the question, and the Back side is the answer. Inconveniently, the fields are called the same way as another concept, making things less clear. Anki has a concept of "front side" and "back side". We glanced over that in the first two radio buttons. So here, the front template is used for the front side. The back template is used for the back side. As expected. However if we looked at “Basic and reverse”, the second card that the note type makes says Back -> Front</code>. So, the back template is used for the front side (the question) of the card, and the front template is used for the back side (the answer) of the card. That's how that note type achieves the "and reverse" part — it creates two cards — one is front (question) to back (answer), and another is back (question) to front (answer). Cool, isn't it? However, as I mentioned, I won't be teaching you how to make use of this, because I don't use it. For the most part, adding two cards per each note, just to learn the question from both sides, is a waste of effort, in my experience. I used to learn languages using anki in the past, and there the reverse thingy was helpful, but for what I use anki right now, it's fairly useless. </hr> </a> Viola! Now you have the necessary knowledge to learn about the card organizing meta that I've made for myself. I hope you'll like it as much as I do! Rather than using a bunch of different decks (as I mentioned, I only have 2), or a bunch of different note types per subject (used to do that, very laborious), I only have a couple of note types. Each of those note types includes two extra fields: one is called “Header” and the other is called “Subheader”. Because the anki browser allows you to search by each field if necessary (header:ruby</code> for example), this works amazingly for card organization. If I need to do bulk actions on a bunch of cards of a certain subject, I can! Just as easily as I would with the many decks approach, and more easily than with the many note types approach. In terms of the note types, I basically only have Basic and Cloze. Except, I split Basic into 4 different note types: the normal Basic one</li> 1 but back side is a codeblock</li> 1 but front side is a codeblock</li> 1 but both sides are codeblocks</li> </ol> I think this is niche? But I use it so much that it made sense to make a shortcut like this for myself, rather than always having to wrap things in a codeblock in the html of the card manually. The approach is pretty simple: you come up with an element (I use <cd></cd></code>) and make css for that element to display it as a codeblock. The note type then wraps {{Front}}</code> in that element like <cd>{{Front}}</cd></code>. Blammo. I will link to my html templates and css file, but be warned: I made this specifically for myself so I give no guarantees it will be a good starting point. html templates main link</a> html templates backup link</a> css main link</a> css backup link</a> As I alluded to prevously, this approach also solves another issue: I am never confused as to what subject I'm currently studying. It's right there at the top! Decks simply don't do this. So, I get to blammo all the cards in 1-2 decks, and go through them all at once; I don't have to experience the annoyance of jumping between 15 or so decks. Card Creation</a></h1> First of all, read this</a>. This blog post has massively helped me create better and more efficient cards. I won't attempt to tldr it, but here are some things that I ended up implementing into how I make cards. Why use many word when few word do trick</a></h2> "What was the year at which Marie Currie did x?" Is very wordy. I'm exagerating in this example, but even still you'll find yourself making cards that use many extra useless words, kinda like the sentence above. Ideally, you will be doing anki until you die. That is a long ass time! (Hopefully?) So all the time you spend parsing words that don't help you arrive to the core of the question, is time wasted. It's not like reading a novel: there reading 20 useless words in a row is fun (allegedly). Anki you are doing for an exact benefit. So cutting down on non-core words is actually crucial. "Marie Currie did x when" That ↑ is all you need. Even the ?</code> at the end is bloat. You don't need it. Your target should be to minimize the amount of time it takes you to process the question. Sometimes adding an extra word can actually help, because it looks more natural to you that way. So, try different approaches for debloating cards, and see what works for you. You will notice just how much faster and easier you can do reviews, because there's much less for your brain to process. You can then use this extra energy to do more cards, or to do the same amount of cards in less effort, to spend that effort elsewhere. Make use of headers</a></h2> The note type approach I use helps the previous point. "jj revset operator that gives you the intersection of two other revsets" becomes: jj revset intersection operator</code></pre> Header jj</code>, subheader revset</code>, and less wordy question. The word operator</code> there I'd remove. Headers and subheaders let you encode a part of your question into a section above the question, that you will be able to skip over most of the time. If you read the question and you naturally remember that the question is about jj, you won't need to pay attention to the header or subheader. At least for me, it's natural to read the question first, and so header + subheader lets you move out a part of the question that otherwise, you would have to read every time. Small optimization that sums up to more than you would expect. One thing per thing</a></h2> Split the question into as many cards as you reasonably can. The blog post I linked above goes into good detail on what that entails, please read it. If you make a question and a part of it could become a whole another question, then it should. It might look kind of ridiculous, but the amount of time you spend is actually pretty big. ❌ question: "shell -> pueue group -> delete a group, moving all of its tasks to the default group" ❌ answer: "pueue group remove" This question is worded in such a way that you hope you'll remember some extra information in parallel. Memory doesn't work like that, you won't be able to "brush off" information in an effective manner. That part should just become its own question if you want to remember it, and be discarded if you don't. ✅ question 1: "shell -> pueue group -> delete group" ✅ answer 1: "pueue group remove" ✅ question 2: "shell -> pueue group remove -> what happens to the tasks when you delete a group?" ✅ answer 2: "they get moved to default group" If each individual question is really easy to answer, all of them will quickly rank up in their intervals, and not take much of your time. So, prefer more cards to less cards, counter-intuitively. If you make one complicated question, you will hit your head against it time and time again, and end up wasting a lot more time overall. Similarly, if you expect yourself to give a big, multi-stage answer to a single question, you should also split it into multiple cards. </hr> </a> Thanks for reading! This took me multiple months to write, lmao. Kinda burnt out on it; you might've noticed towards the end. Hope my experience will be useful to you! addendum</a></h1> I'm writing this on 2025.05.19. While most things hold up exactly as before, I'm now using a slightly different approach in terms of taking in new cards. Not entirely sure if it ends up being more or less efficient, but the consistency of it is awesome. I learn for the love of the game, so there isn't necessarily some deadline up until when I have to learn everything I want to. What matters far more to me, is to ensure that I never burn out on anki. I found that for my type of cards, I can review 70 every day. I can (and did, before finding this method) in theory do more, but I know that more than 70 will end up burning me out, if prolonged. This is a type of thing that you get a feel for after a while of using anki, so don't worry if you don't know your number yet. </blockquote> I found a way to review exactly my limit of cards every day, without fucking up the algorithm too much! First, a setting that this entire approach relies on: Deck Options -> Display Order -> New/review order -> Show after reviews. Now, when we start doing our reviews for the day, we go through all the red and all the green cards first. Say I have 15 reds, and 45 greens. That's 60 total reviews to go through. I got 10 extra in me though! And those 10 extra are for the new cards :D So, as I review, I check every now and again: how many reviews (not new cards) are left</li> how many reviews I've done so far</li> </ol> After I get through all the reds and all the greens (unless they are already more than 70, I elaborate on this later), I check 70 - total_reviews</code> to figure out how many new cards to take in today. Your total reviews are shown on the main / home screen, so that's what I'm relying on. I wonder if there's a plugin that would show that info while I'm reviewing! For easier math, I set the amount of daily new cards to 100. For reasons I explained in this blog post above, obviously we aren't meant to gulp all that 100. We simply take from that 100 every day, however much we can handle (70 - total_reviews</code>). Why this appproach is amazing, is that it's quite dynamic while being consistent in terms of my effort. You have a low amount of reviews? Yipeee you get to get more new cards today! Too many reviews? No big deal, we simply take less / no new cards. But what happens if you have more than 70 reviews? This happens to me every time I rotate my sleep schedule, for example. Or say you miss a day for other reasons. Generally, it's a bad idea to gulp all the reviews at once, that you got from the previous day that you skipped. Sure, the anki algorithm works better this way, but that's only in theory. In practice you are human. Additionally, you're creating a fucky effect: if you get a sudden spike of reviews on a given day, this spike will repeat some days later (although it won't be as strong). This is why instead of gulping all reviews in a bad situation like this, I tend to instead increase my daily reviews temporarily, until the extra cards are all sorted out. This happens over the course of multiple days, and so the spike repeat is not as big of an issue. Deck Options -> Display Order -> Review Sort Order -> Ascending retrievability is quite important to make this as effective as it can be, to not fuck with the anki algorithm as much. So! If you take the same strategy, my "up to 70 reviews" approach makes even more sense. In the general case, my reds + greens are less than 70, and I fill the rest with new cards. So when shit hits the fan, what ends up happening is that reds + greens fill up the entire 70, and I simply don't take new cards for a couple of days. So, this approach has built in overflow protection! Although it's not like you should want to use it :p To add, when I get an overflow, I increase my cap from 70 to 80, until it's sorted. I consider a shitfan sorted, when to get 70 reviews, I'd have to take new cards. At that point I go back to the 70 cap, and take as many new cards as fit into the 70 cap, rather than the otherwise increased 80. In the case where I get more than 70 reds + greens, but there isn't an overflow from me skipping a day, the same rules apply, except I don't touch the cap. So, I basically allow the remaining reds + greens go to the next day, and let them get sorted out automatically via me taking in less new cards. Quite dynamic! Aside from the overflow protection, what I love most about this approach, is that I never get "unlucky". I never get too many reviews on a day where I'm exhausted. I never get too little reviews on a day where I'm extra energetic. It's always the same exact number of reviews :D And what's fun about this, is that it lets you more clearly tell what your cap is. If you do exactly 70 (or your other number) reviews every single day, you will realize sooner, whether it's too much or too little. My cap used to be 65, but over time I noticed that I wanted to do more, and so I increased my cap to 70. I want to increase it again, but I'm intentionally waiting for a while to make sure that would be the correct move. Don't rush when changing your cap, and change it by small amounts. rust for... scripting? Axlefublr — Sat, 04 Jan 2025 00:00:00 +0000 If the title of this blog post is a genuine question you have, and you want to just skip to the most reasonable solution: use cargo-script</spoiler> why</a></h1> I recently realized that the two languages I like using, fish shell and rust, are ridiculously far apart. I wanted to find myself a language I could use for scripting that is non-viable to do in fish shell, but too annoying in rust. Turns out, there are not really any languages that fit all of my criteria! Python, Ruby, Crystal, Ocaml, Nim, Julia, Go, Nushell — these are the languages I tried, or considered going for. I actually wrote the majority of the blog post on my adventure looking for a good programming language, but found what I wrote kinda boring and soulless, so I won't get into why each of those languages didn't fit me. Once I'm "over" something, it becomes incredibly boring for me to talk about it, and so I missed the train of writing a blog post on that, lol. The TLDR is that I came back to rust, reinvigorated to use it more! on rust</a></h1> Rust has always felt really solid to me. But like a cock, it is sometimes too hard to work with. After trying out so many other programming languages, and spending the most time and effort on Ruby, I re-started to appreciate that solidity of rust, and changed my approach to the language a bit. Inlay hints turned out to be visual clutter I came to accept. Removing them by default, and only toggling them when I need them, has helped immensely to look at rust more calmly. Diagnostics in rust are very helpful, but sometimes overwhelming. Similarly, once I see a bit too many diagnostics, I disable them. Once I need the extra advice, I enable them back. I was constantly fighting rust, getting annoyed at how I'm meant to do seemingly simple things. Getting the modification time of a file is kinda cumbersome in terms of the syntax, working with files is often way too involved, calling external commands is boilerplaty; especially so once you literally just need the stdout as a string. Often times it felt like rust overcomplicates things. For good reason, mind you, I just happen to not care. I'm a very selfish programmer, I don't need cases I won't come across to need to be solved. But, it is the language that rust is, and some code will look boilerplaty / ugly. I've come to accept that, instead of being annoyed that my code isn't syntactically perfect. Now I'm more okay with some parts being kinda hard to look at — I will simply skill solution my way into being used to it. And lastly, rust has always felt like responsibility. Making plugins for neovim in lua had the nice benefit of that I didn't have to. I could just have some code in my own config for a couple of months, completely working. And then, once I'm ready to, I could package it all nice and prettily. Fish is even more amazing than that, because you can have a lot of callable executables in single files, thanks to a technique I use and will probably talk about in the future. So, the pressure of writing something new in fish is also really really small. Starting up a new CSS extension with stylus is slightly a process, but it's straightforward and fast enough where it's not that big of a commitment. If I want to, I can easily shrink the ridiculously large sidebar with css for some stupid website, without it breaking my flow particularly much. Rust is in a completely different league. I have always wanted to avoid using rust because of the sheer pressure I put on myself. First, I need to come up with a name for a project, and create a new repository and directory for it. Nope, you already lost me! Coming up with a project name and being happy with it are really fucking difficult, and are not something I want to do for a on-a-whim script that probably only I will use. Then, setting up rustfmt config, github action for auto-making releases, keeping track of the version and the versioning tags, remembering to push them, writing DOCUMENTATION in both the readme and source code with ///</code>, picking apart which information should be in which side of the documentation... IT'S TOO MUCH! but not anymore</a></h1> I created myself a new system that allows me to use rust for scripting in a pretty fast and straightforward way. No more various bullshit to take care of for the 0 users I'll have — sheer selfish programming! Let's start where I started, to figure out why I ended up creating my own system. scriptisto</a> is a really neat program that I used for the various languages I have tried. It allows you to use a compiled language for scripting, conveniently! You can run that script just like it's written in an interpreted language, because scriptisto can be used as a shebang. So, something like ./script.rs</code> is possible. The first time you run that script, scriptisto compiles it. On the following runs, it simply resolves to the compiled binary and runs that, without needing to recompile. I've had an amazing experience with scriptisto, and would heavily recommend it. However, it was strangely slow with rust! After the first run, the following runs still had awful startup time. Around 3 times slower than ruby! And ruby has a pretty shit startup time already. When you can tell the startup speed by an eye test, that means it's really bad. So, I decided to try using cargo-script</a> instead, and it indeed didn't have that issue! The following runs were definitely fast! </hr> </a> Until they weren't... One of the first programs I wrote is called velvidek.rs</code></a>. I don't use the number row; instead, right meta key + fdsrewvcxa are my numbers (1234567890). Velvidek takes those letters, and replaces them with their appropriate digit. Using this program, I can shim in support for my number layer, without requiring me to press the right meta key. Now instead of having to do fg %2</code>, I can just do f d</code>, thanks to the fish function I made that made use of velvidek. Very helpful and important addition to my suspend-based workflow</a>. I was pressing f</code> to go back to the suspended process, and noticed the operation be slower than I expected. I use fish shell's time</code></a> to check how long it takes for velvidek to execute, and see ~70ms. Well holy shit, that is entirely too slow! For a program as modular, small, and fast as this, this is ridiculously long. I was running velvidek as a script through cargo-script, so, using the shebang #!/usr/bin/env run-cargo-script</code>. I decided to check how long env</code> takes to figure out the path to the binary. 3ms. So, env is not the problem here. It turns out that cargo-script is wasting a lot of time doing something. Well this is concerning. But interestingly, a fish script takes around the same time! ~80ms for a roughly equivalent functionality script I tested. So, at least cargo-script is faster, or on par with a shebanged script in a different language; that's good news. The bad news is that it is too slow regardless. When you write a fish function, the time it takes to execute it is in the nanoseconds. When you turn it into a script, it gains these extra ~80ms of startup time, apparently, and so does a shebanged rust script. cargo-script caches compiled binaries as I mentioned, so I decide to time how long it takes to execute, if I call the compiled binary directly. 3ms. It seems like it takes around 3ms to start a process on my computer, considering that both env</code> and a random rust binary take around the same time. So, in other words, the binary itself is not slow; cargo-script is simply wasting time. My guess was the following: cargo-script tries too hard to not recompile, massively slowing down the general case. So, if I make that process stupider, I'll gain a faster general case, while probably having to recompile unecessarily more often. A tradeoff I'm absolutely willing to make. My idea is to compare the modification times of the script and the compiled binary. If the binary is older than the script, let cargo-script continue like normal, to recompile it. If it is not older, run the binary directly, and forgo asking cargo-script for its opinion. This sounds like such an obvious solution, that it's weird they are apparently not using it. When you feel smarter than a developer who's more impressive than you, you are probably wrong, and that's what I assumed as well. I'm trying my best to not reinvent the wheel though, and this pre-step possibly working would allow me to continue using most of the functionality of cargo-script, without having to recreate it for myself, to allow for optimization. Alright, first run! The binary is older than the script, and the execution gets forwarded to cargo-script. Fair enough. And right about now, it should recompile. Right? Right??? It does not. And so my pre-step just infinitely transfers control to cargo-script, infinitely having that ~70ms startup time. Worse yet, the time difference between the binary and the script is ~5 seconds. Not milliseconds. So, at which point do I consider the binary "old enough" or not? Going in this direction seems fruitless. And I forgot to mention something: when using cargo-script, rust-analyzer does not help you. It requires there to be a Cargo.toml to give you lsp capabilities; if you don't have it, it gives up and does nothing. So, for a good developer experience, you kinda need to have a directory where you write the scripts to begin with, and then something that would compile that source code into a cargo-script compatible single-file script. Considering that I already had a "workspace" directory, I thought "fuck it" and went ahead to fully forgo using cargo-script, in favor of making my own system. It will be less convenient, but far faster to start up. my system</a></h1> A "workspace" directory named wks</code>. I use this place to write the scripts for the first time. There's src/main.rs</code> and Cargo.toml</code>. Just what is needed to make rust-analyzer work. Once I finish writing a rust script, it's now time to export it. I have a (rust) script that takes main.rs and Cargo.toml, and joins them into a single file. The path to the target file I want to write to, I specify as the first line in main.rs, in a comment. Primary link</a>, backup link</a>. While writing this export step, I started thinking about how I'd make a script executable. I would probably write another script, that would act as the program in the shebang. But I found something more elegant! What I want, effectively, is to: not pollute where the scripts are, with their compiled binaries</li> to execute a script, you simply use the script name (for example, velvidek.rs</code>)</li> </ol> To achieve that, I can make use of $PATH</code>! Once I compile a script, I will rename the resulting binary to the name of a the file, and put that binary somewhere on the PATH</code>. This way, I'm typing in a name of a script to execute, but sneakily I'm actually executing the compiled binary stored somewhere else. This is where the second script comes in. This one is in fish though: primary link</a>, backup link</a>. While the export script just writes to the target script file, this is the compilation script. It compiles the project, and copies the resulting binary somewhere on the PATH. While one ensures my work is backed up (as a single file "script" in my dotfiles repository), the other one actually makes sure it's executable, by providing a binary with the exact same name, that I can call. A very sneaky and elegant solution, I'd say! :3< In the future, if I need to edit some rust script, that's where the import script comes into play. Primary link</a>, backup link</a>. It takes a path to a rust script that I exported into previously, splits it into main.rs and Cargo.toml, and writes those files in the workspace directory wks</code>. After I import, I'm ready to edit the script in my workspace, to then export it back again. Thanks to my helix fork</a>'s command harps, running all of these scripts is really easy, and this has become a way nicer workflow than I expected! Now that rust is so fast to get running, I'm way more excited to write it, and I already am rewriting some things as rust scripts, when they were written in fish before. It's super nice! stray from defaults Axlefublr — Thu, 02 Jan 2025 00:00:00 +0000 Vim has made a stupid design decision, and we're still eating shit many years later. It prioritised mnemonics, rather than ergonomics. The issue is pretty apparent: mnemonics are helpful for the first, like, week while you're learning vim for the first time. And then many years later you still end up using the same non-optimal mappings. </hr> </a> One of the most frequent things you do in a text editor, is copy. And yet it's mapped to one of the most annoying keys to press: y</kbd>. While powered by a big stretch of a mnemonic that we just came to accept: "yank". And yet s</kbd> sits there undisturbed, in one of the most prime finger positions on the home row, doing what cl</code> can also do. Don't get me wrong: I loved using s</kbd>, but it is too convenient of a placement. </blockquote> I hate pressing p</kbd> almost as much as pressing y</kbd>. It is another example of an 😩 key used for one of the most common actions. Except, pasting is probably more common than copying. o</kbd> is one of the nicest to press keys, yet it's there for a fairly niche action: creating a new line. What I find myself doing the most after creating a new line, is to create another line. Because o</kbd> puts you into insert mode, the natural way to create another line is by pressing enter. Yet, the hand motion of switching from o</kbd> to Enter</kbd> is pretty cumbersome. What is the most common usecase for A</kbd>? In my experience, it's to add in a ;</code> or a ,</code>. However, if you correctly use both shifts, the hand movement to do an action like this is a bit too ridiculous: for such a common usecase, having to move your pinky aaaaallllll the way from the right shift to ;</code> ends up compiling into an annoyance. The choice of a</kbd> is also strange in a different way. To insert at the left of the cursor, you press the right key (i</kbd>). To insert at the right of the cursor, you press the left key (a</kbd>). ??? you can stop eating shit</a></h1> Defaults are made to be CHANGED from. It's great when they are good to begin with, but that's not always the case. Do not be afraid of change when it can provide you a much nicer experience. My copy key is now s</kbd>. What's the mnemonic? "Steal"? Wrong question. I don't need a mnemonic! If the mapping feels right, your muscle memory adjusts pretty quick! Now I don't have to travel across the Alps just to copy something: the key is on my home row. My paste key is o</kbd>. Much nicer to press than p</kbd>! And in addition, something like yyp</code> is now sso</code>, which I find to simply be much more enjoyable. Insert new line is now on a</kbd>. Now when I insert a new line, the motion of my right hand to reach Enter</kbd> is much smoother! Smoother even if I do "insert new line above" (A</kbd>) first; all I need to do is slightly move the right pinky from right shift to Enter</kbd>. Insert after the cursor is on p</kbd>. This was risky in my head, because I don't like pressing p</kbd>. But very quickly I realized just how much nicer it is than a</kbd> for the purpose. First of all, it is on the right side of i</kbd>! So, i</kbd> and p</kbd> now play along with a consistent semantic of "this one is on the left, this means before" and "this one is on the right, this means after". But even better than that, appending is AMAZING now! The hand movement to append a ;</code> or ,</code> at the end of the line is way smaller now, and feels really comfortable. Also generally, pressing right shift is more difficult than pressing left shift anyway; so overall there's less hand movement for something that I do really frequently, especially while writing a blog post for example. </hr> </a> After changing these, it took me maybe two days to get used to the new mappings. This is simply because of how much more fitting they feel in my head, and to my fingers. You will have your own gripes that you will solve differently than me, but I wanted to shed light on that it can be really beneficial to change defaults, even when they are as strong-rooted as the ones I listed. It's true: a lot of other programs will replicate vim, and have semantically fitting hjkl</code>, y</code>, p</code>, etc mappings. What do you do about that? Personally, I just context switch, or reconfigure the mappings. This may seem like a lot of effort, or a non-ideal solution, but look at it from a different lens: why would you sacrifice your experience in the place where you spend most of your time (your editor), just for some other program to feel consistent? I do agree, context switching is annoying, but can be learned: if you have a strong thought of "this is a different program", you can eventually stop caring that its mappings are inconsistent with what you remapped. Or, you know, remap them in that program as well. suspend is actually neat Axlefublr — Tue, 31 Dec 2024 00:00:00 +0000 Part of why I still use kitty</a> is because its window manipulation is goated. You can create windows (panes), tabs, overlay windows (panes) and os windows using hotkeys. That's cool enough on its own, but you can do all of that from a script too! This lets you integrate window manipulation into a bunch of places, so it's quite workflow-building. Say I'm in helix, and want to run some shell command. I can of course use :sh</code>, but it's pretty cumbersome, so I'd rather use my actual terminal. Not only can I just create a new pane, I can create it in the same cwd as the current one, or as the same cwd as helix is in (my helix fork</a> exclusive feature), or in the parent directory of the current helix buffer (helix fork specific also). This isn't a post on why kitty is amazing, because as I expressed in the past, I hate kitty. I more so want to shed light on that my window manipulating workflow is super solid, so there was never a need to look into the shell feature called "suspending". Plus, it's kind of confusing and last time I tried it, it felt wonky. </hr> </a> I happened to be reading a blog post</a> by Julia Evans some time ago, and it goes on to explain the benefits of actually using job control. (It was a great read but) at this point I don't really remember a single point; all I remember is that "job control can be kinda wonky but it's also super neat". I decided to give it another try. While in helix for example, instead of opening another pane to run a shell command (only to close the pane right after), I would instead suspend helix and execute the command in the shell that I already had open. Very very quickly I realized that I absolutely love it! command output</a></h1> When I create a new pane to run a shell command, I'll probably close it right after. Having windows I forgot about open feels messy, after all. But when I close a pane, naturally I lose all the output of the commands that I ran previously. This doesn't happen with a suspending workflow! The output of previous commands actually stays and I can look at it again as many times as I want to. Better yet, I can switch back and forth between helix and the shell output very quickly — as fast as I would be switching between multiple (fullscreened) windows. (But with the benefit of not needing to clean anything up) This factor really started to shine once I was fucking around with colors using pastel</code>. I couldn't quite get the correct lightness factor on some color, and so I was going back and forth between helix and my shell, using the previous color (displayed in the output) as the input to a new pastel darken 0.01</code> command; then, going back to helix to try out where I was actually using the color. This worked so amazingly for me because I never felt like I needed to clean up a pane after I'm "done". With a pane, I might've closed it early and lost output that I then would realize I need, a couple of seconds later. And in the same fashion, keeping multiple windows open feels quite bloaty, and I see it disrupt my worklow in a way that suspending simply doesn't. toggle hotkey</a></h1> Another thing that helps a lot in the workflow, is how natural it is to make a hotkey for it. With a pane, you need a hotkey to create a window, and a different hotkey to switch between windows. Then maybe even another hotkey to switch windows backwards. I don't need that with suspend! The hotkey is simply ctrl+z</kbd> to suspend; and I made a hotkey in my shell to run fg</code> — that puts the latest job into the foreground. I do something in helix and realize I need to run a command. ctrl+z</kbd></li> run command</li> ctrl+z</kbd> again, now to go back to helix</li> FIN</li> </ol> Rather than: hotkey 1 to create a new pane</li> run command</li> hotkey 2 to close it</li> FIN?</li> oh fACK I needed that output, now I have to repeat this process to get it back</li> </ol> </hr> </a> Neither of these are particularly that strong of arguments; ultimately this suspending workflow simply felt neat. So try it out, maybe you're be as overjoyed as I am! However, I was still missing a part of my windowing workflow power. As I mentioned, I can do something like "create pane in the working directory of helix" or "... in the parent directory of the current helix buffer". The pane creating hotkeys know about this info because I explicitly pass it; how would suspend know about it? By me forcing it to know! 😈 </hr> </a> In my helix fork, I made the suspend action write the current buffer's parent directory to a path, and the current helix cwd to a different path. Then for yazi, I wrote a small plugin that writes the current directory path to both of those files every time I change directory. Now, I have a hotkey in my shell on ctrl+y</kbd> that toggles between the two paths listed in those two files. So now, instead of needing to create a new pane in some specific directory with dedicated mappings, I can retroactively cd into the directory from which I want to execute the command. I'm working on a new script in helix, and want to run it. I suspend helix, and press ctrl+y</kbd> to switch to the parent directory of that script, and simply do ./script.fish</code>. I press ctrl+y</kbd> only once, assuming that my shell's cwd and helix's cwd match up; if they didn't, I'd have to press ctrl+y</kbd> twice. Note that my ctrl+z</kbd> is actually on capslock+w</kbd> and ctrl+y</kbd> is on capslock+e</kbd> So these two hotkeys are actually way more ergonomic to press than the real ctrl+z</kbd> and ctrl+y</kbd> would be </blockquote> Me storing helix's cwd solves the other part of of the windowing workflow — "create pane in the cwd of helix". Except, it does it better. With the windowing workflow, I need to proactively think about how to create my new window. "Which cwd do I need?" Even if I just default to helix's cwd, I'm bound to have to use a different mapping to open windows from helix, than I usually would anywhere else. And even then, I still need to proactively think about creating windows in the parent directory of a buffer. The suspend workflow wins here yet again, because I fix my current working directory, instead of having to prepare it. The thought process in this workflow is way simpler. I need to execute a command</li> suspend</li> starts writing command</li> "oh right I need to execute it from the parent directory of that buffer"</li> presses ctrl+y</kbd></li> continues writing command and executes it</li> </ol> I don't even need to delete the command and then re-write it; the cwd fix is on a hotkey! So this process is incredibly smooth 😋 </hr> </a> I hope I was able to show you how a suspend-driven workflow can work really well! Try out using job control more, maybe you will discover that you love it too! safety razors slap Axlefublr — Mon, 30 Dec 2024 00:00:00 +0000 Shaving is a massive hassle. Because I'm trans, it's even hassler for me than to the average person. Elecric shavers are pretty low effort, but they also don't cut that close to the skin, so it's a good strategy to use when you have a lot of hair, but pretty ass if you don't. To get a pretty ass though, you need the power of an actual razor. But those have their own plethora of issues: they may cut you, "dribble" on the skin, introduce ingrown hairs, overall feel too rough and damage your skin. You can pick your razor to have more blades to mitigate some of these issues, but then the problem is the sheer price. I'm broke as hell! I can't replace the blade as often as it's recommended, so I end up with a shitty razor for most of the time. If I go for a cheaper blade, I just start with a shitty one, lol. Shaving sucks, doesn't it! It's the thought that I accepted for the longest time. But just recently, my friend recommended me something that made me want to shave again. Over the past couple of days, I shaved my entire body. This barely ever happens! It's so fun now! safety razors</a></h1> This product name sounded strangely vague to me! A safety razor (image 1) is basically a holder for the classic razor blades (image 2). I had no clue what they were used for before! So, a safety razor takes a razor blade, and bends it at the perfect angle to give you two bladed sides that you can use to shave with, making the razors safe to use. Interestingly, in russian, "razor blade" is sometimes literally called "dangerous razor". I was warned that you need to be really careful when shaving with a safety razor — unlike your usual razor, you don't have the spinny bit that will follow the shape of the skin that you're shaving — you need to uphold that invariant yourself, otherwise you will get cut. The friend that suggested a safety razor to me said she cut herself 6 times! Naturally I got anxious about that, and thought "nah I'd win and only get cut 2-3 times". Eventually the safety razor arrived and I got to shaving. Turns out the name wasn't a lie! It is indeed safe! Because of how sharp the razors are, I don't need to apply any pressure — I basically just let the handle dramatically fall against my skin... and it just works?? In the end I didn't get cut a single time, so I guess I did win! The process of shaving is pretty similar to a normal razor, but you do need to be more careful and slow. Because it's just a single razor rather than 2-5, you can't just force the razor to do everything in one go — it is pretty important to first shave with the grain, and then against the grain. Don't forget to apply shaving cream both times! A normal razor has this colored line that somehow relaxes your skin after shaving across it; a safety razor doesn't have that. And so you have to do the job of this colored line yourself by making sure you use shaving cream / gel more thoroughly. Another tip which I've been using prior but not as conciously: warm up the area you plan to shave. Most straghtforward way is to apply some very warm water to the area. This allegedly makes your hair softer, making it easier to shave off. </hr> </a> So, I finish shaving with a safety razor for the first time, and wow! My skin feels FAR less damaged than it usually is with a normal razor. The experience itself is actually kinda... fun? When was the last time shaving actually felt fun! As I mentioned, over the last couple of days I went ahead and shaved my entire body. It's usually a massive chore, but for once I feel excited to shave, because my razor actually does its job as advertised! Nay, better than advertised! And best of all, it is now cheap. REALLY fucking cheap. The replacement blade for my previous go-to razor cost me around 6$. More precisely, I could at minimum buy 2 at a time, costing me 12$. I will remind you: I am very poor, and so I couldn't pay that price often enough to get the best performance out of the razor. Now, for that same 6$, I can get a HUNDRED replacement razors. They are dirt cheap, and perform better than "peak" normal-razor-blades. Better shaves, less damaged skin, cheaper, more enjoyable. Safety razors are amazing! Try one out if you haven't before! best find & replace tool I found Axlefublr — Mon, 23 Dec 2024 00:00:00 +0000 I used to do magic with the quickfix list back in neovim, that gave me a pretty good find & replace experience. However as you may know, I switched to helix. It can be very barebones at times, compared to the shenanigans I wrote for myself in neovim. My find and replace now is mostly just the “find” part — I use helix's searcher, and then visit each place individually to modify it how I want. It's as laborious as it sounds. "About time to change this" I decided, and went to look for an interactive find & replace tool. First thing I found is serpl</code></a> It was quite precisely what I wanted! However, I quickly noticed a bug</a> that literally disintegrated the UI over time. Non-0 chance I could fix it in my fork like I tend to do (apparently), but I'm not in love with the software enough to bother. For what it's worth, it would be strange for a bug as big as this to exist for everyone. If you're interested in a TUI find & replace tool, serpl might still be for you! Maybe the stars align and the bug doesn't happen for you ✨ Conveniently though, serpl mentions another similar tool at the end of the readme. Honestly it's almost too nice, because it is just directly better for the most part! (if we exclude the bug I experienced) The awkward name of this tool is repgrep</code></a>. Nope, I didn't misspell ripgrep</code></a>! Seems like the idea for the name is “ripgrep, but replace”. Similarly to ripgrep, the binary you will be using is not that wordy: rgr</code>. Once again, the semantic of “rg, but replace”. The beauty of repgrep for me, is that it just uses ripgrep under the hood. Because of this, you won't need to learn any new arguments / flags to use repgrep — it just passes along the arguments to rg</code>! So if you know rg</code> flags, you automatically know rgr</code> flags :D You start repgrep by specifying the arguments to ripgrep, mainly the search pattern: rgr maximi</code></pre> And find yourself in the TUI: It's as natural as it looks, so I won't spend time explaining all the hotkeys. You can look at them by pressing ?</kbd>. Let's have a look at replace mode, that you get to by pressing Enter</kbd> or r</kbd>. The interesting part of the design decisions, is that while entering your pattern, Enter</kbd> doesn't confirm! Instead, it inserts a newline: You accept by pressing the awkward hotkey ctrl+s</kbd>. Strange decision, but I respect the thinking behind it. Letting the user insert newlines just like that is pretty helpful, considering that neither \n</code> nor \r</code> work. However still, accepting happens way more frequently than inserting a newline. Unfortunately, there is no configuration, so I couldn't change it in a normal way. I maintain a helix fork already, what's one more? Especially not scary considering how long ago the most recent commit was. So, I forked repgrep to change the behavior of enter. Now enter</kbd> accepts, alt+enter</kbd> inserts a newline. And that's how I finally have a nice find & replace tool! helix is ridiculously consistent Axlefublr — Fri, 13 Dec 2024 00:00:00 +0000 In helix, these two actions exist: copy_selection_on_next_line copy_selection_on_prev_line</code></pre> The default hotkeys for both of them are shift+c</kbd> and shift+alt+c</kbd>, respectively. From the name I instantly assumed: "ah, it's the usual "add multicursor on the next line" and "add multicursor on the previous line"", like practically every multicursor implementation has. I've talked about the elegant consistency of helix in this blog post</a>; turns out the idea of "selections matter, not your cursor" applies here as well! showcase</a></h1> </video> You create a new cursor below the current selection, not the current line! So you could possibly make use of this by selecting two lines, and then effectively make cursors on every other line. The usecase that comes in mind immediately is some long if</code> chain, where the bodies are all a single line, and you want to change something in all (or some) of the conditions / bodies. </video> To be fair, I have yet to use this for anything, but found the consistency really cool. Being able to express editing desires in such an elegant way is part of why I switched to helix! newest helix master features Axlefublr — Tue, 10 Dec 2024 00:00:00 +0000 As you may know</a>, I maintain my own helix fork</a>. Recently I noticed a huuuuuuuge burst of new commits, and here's what new features I found! cd improvement</a></h1> The :change-current-directory</code> (:cd</code>) command now more closely mimics the useful behavior of cd</code> in the shell: With no arguments (:cd</code>), it now changes directory to ~</code> ($HOME</code>). :cd -</code> changes directory to the most recent one. So, if you :cd ~/Documents</code> and then :cd ~/Downloads</code>, :cd -</code> will put you back into ~/Documents</code>. auto-trim trailing whitespace with a caveat</a></h1> The insert_newline</code> action now trims that line's trailing whitespace. So if you make custom mappings for insert_newline</code>, or far more likely when you press Enter</kbd> in insert mode, that line's trailing whitespace is automatically removed. </video> While this is cool to have and will fix most trailing whitespace moving forward, the issue is the moving forward part. Somehow we still don't have a :trim</code> command or on-write hooks that would trim for us, so this on-newline behavior won't help you clean up a codebase — only to not mess up (as much) when writing a new one. auto-continue line comments</a></h1> Our second on-newline feature! Although this one doesn't depend on the insert_newline</code> action, and will happen even if you use something like o</kbd> / O</kbd> </video> This feature has actually been in core for about a month I think, but I didn't rush to rebase to get it because honestly I didn't want the feature. I used it back in neovim, and I found it to annoy me more often than help me. An extra // </code> / # </code> / etc to type in is not as much effort as possibly having to fix them. Additionally, in neovim the operation felt very wonky visually. The wonkiness is not an issue in helix, as this is a core feature, not something that was tacked on, so that's crossed out. However the "annoying" part may still remain, as after ~1 minute of fiddling with it, I found a bug¹ when you try to extend a comment upwards, when you're at the first line in the file: </video> Interestingly, there is no option to disable this auto-comment-extending behavior. ¹ Around two days after publishing this blog post, the bug is fixed! This is surprisingly fast response speed for helix — generally things move reeeeeaaaally slowly. This fills me with determination! Additionally, there is now an option to disable this behavior 🥳 Set continue-comments</code> in the [editor]</code> section to false</code>, if you want to. path completions</a></h1> Now you get autocomplete for filepaths! :D </video> If you were using my fork prior, you already had these! I've been following the PR that implements this feature for a month or two, and I had it merged into my fork. I'm quite surprised to see it get merged into core! So now that's one less responsibility on my fork. But also, before this point, there was a bug where you could only complete a single filepath on a given line. If you tried to complete another path, the completions wouldn't show up. This is no longer an issue! This feature is enabled by default, but if you wanted to disable it, set the path-completion</code> option in the [editor]</code> section to false. default comment token</a></h1> For unrecognized languages (if you just open a file with no extension and no inferrable text, for example), the comment token used to be //</code>. Now it is #</code>. Makes sense, considering that more often than not, an unrecognized file is a config file that probably uses #</code> for comments (if it even supports them). conf "language"</a></h1> You might notice that the syntax highlighting for random .conf</code> files is now gone. This happened because of a commit that (as it says in the commit message) “Fix language configuration for .conf files”. “Fix” my ass. Put this in your languages.toml to bring it back: [[language]] name = "hocon" file-types = [ "conf", { glob = "**/src/*/resources/**/*.conf" }, { glob = "*scalafmt*.conf" }, { glob = "*scalafix*.conf" }, ]</code></pre>safer paste</a></h1> If you use paste</code> in insert mode, that makes an undo "checkpoint": </video> I needed to press u</kbd> three times there, to undo the second line. Previously, a single u</kbd> would undo the whole line. This is pretty great! It's somewhat often that I start typing in a line and then paste from my system clipboard, only to realize I pasted in the wrong thing. Now after I undo, I don't lose the extra text I typed in before the paste. About clipboards... configurable clipboard providers</a></h1> Previously, helix figured them out automatically. Now, you have an option to set them explicitly. bit from the docs:</a></h2> clipboard-provider</code> — Which API to use for clipboard interaction. One of pasteboard</code> (MacOS), wayland</code>, x-clip</code>, x-sel</code>, win-32-yank</code>, termux</code>, tmux</code>, windows</code>, termcode</code>, none</code>, or a custom command set. [editor.clipboard-provider]</code> Section</a></h3> Helix can be configured wither to use a builtin clipboard configuration or to use a provided command. For instance, setting it to use OSC 52 termcodes, the configuration would be: [editor] clipboard-provider = "termcode"</code></pre> Alternatively, Helix can be configured to use arbitary commands for clipboard integration: [editor.clipboard-provider.custom] yank = { command = "cat", args = ["test.txt"] } paste = { command = "tee", args = ["test.txt"] } primary-yank = { command = "cat", args = ["test-primary.txt"] } # optional primary-paste = { command = "tee", args = ["test-primary.txt"] } # optional</code></pre> For custom commands the contents of the yank/paste is communicated over stdin/stdout. </hr> </a> Yes it really said “wither” </blockquote> This is of course cool for the (I think unlikely?) situation if your clipboard provider didn't work, but what I find more interesting is the custom clipboard provider. As you see in the example they specify, you can straight up just use a random file. Interestingly, that's a hack to get your latest register to stay across helix sessions (unless helix deletes the file on exit, which would be mean). If you use my fork though, you don't need to bother doing that, as I merge in a PR that adds persistence to various things, including your default register. However: the "primary selection" (register *</code>) is something that I never use, so I could potentially change it to give me fairly arbitrary behavior. I could easily write a script that would act as my *</code> register, and do different things on paste / yank. For the most part, actions like shell_pipe</code>, insert_output</code>, append_ouput</code> along with command harps (my fork's feature) already provide you this "easily accessible script" behavior, but maybe you can come up with a strong enough contender that would make sense to put directly as the *</code> register. Share your ideas with me on bluesky</a> or discord</a>, I would love to hear them. configurable default register</a></h1> The default register used to be just "</code>. Used when you don't explicitly specify any other register. But now, there's an option in the [editor]</code> section called default-yank-register</code> that you can set to override that. Aside from path completion, I feel this is the biggest "fuck yes finally!" recent feature. In neovim, there was some option (don't remember lol) to let you use your system clipboard as your default register. So if you set it, you could just y</code> directly into the clipboard and p</code> directly from the clipboard. I used it, actually! And I loved it. And now, helix has it too 🥳 However, unsurprisingly, it's better — you aren't restricted to just set the +</code>/*</code> registers as your default ones, you can use whichever you want! It could be just a</code>, or even the /</code> register, terrifyingly: that would give you the behavior that all yanks set your current search. Or remember that custom clipboard provider feature from the last section? Nobody is stopping you from combining these two features, and setting your default register to behave differently somehow. Default register set to *</code>, and default provider for *</code> is your custom script. ??? -> profit. Currently, y</kbd>¹ yanks to default register for me, and Y</kbd> to the system clipboard. It was more of a workaround than preferred solution, since now I'll just set default-yank-register</code> to +</code> to sync it to my clipboard, and I'll never need to worry about it again 🥳 ¹ this is technically a lie, because it's s</kbd> and S</kbd> that are my yanking hotkeys (I hate pressing y</kbd>), but the example would be less clear if I said it to begin with </blockquote> Keep in mind, the default register using your clipboard directly may introduce overhead. Meaning: some operations, especially when you yank / paste in bulk, may slow down; sometimes considerably. But I'm saying this from experience in neovim, and even then it was only noticeable in the most obscene of situations. So, it's something to consider, but not something to particularly worry about. word-bounded autosearch</a></h1> *</kbd> lets you search for your selection. But it slightly changed! Now it places \b</code> around the selection to only match it word-bounded. In other words, if you *</kbd> on word</code>, you will no longer match wordword</code>. The default behavior of *</kbd> changed to the new action called search_selection_detect_word_boundaries</code>. The old behavior is in the action called search_selection</code> and can be accessed by pressing alt+*</kbd>. Arrest me: I was just booting up to complain that I don't like this new default behavior because \b</code> doesn't work for non-word characters... But they thought of this! If you select *just*</code> and press *</kbd>, it will search for *just*</code>. If you select just</code> and press *</kbd>, it will search for \bjust\b</code>. So it's actually being smart about word boundaries, and only applies them when they would work. Bravo, Vince. </hr> </a> All of these new features are now also available in my fork</a> 🥳 I liked writing this blog post, so I might continue making these "recent new helix features" blog posts in the future. Want to make sure to not miss them? Add this link</a> to your RSS reader! Don't have an RSS reader? I recommend nom</a>. my usb drive experience Axlefublr — Fri, 15 Nov 2024 00:00:00 +0000 I hate buffering, so I download practically every youtube video I watch using yt-dlp. That's all fun and great, however my 256gb laptop is slowly running out of space! Well... that's a bit of an overestimation: I have hours upon hours of content downloaded and am still at only 71% usage, but that number freaks me out regardless! You may reasonably suggest to upgrade my SSD to something like 1 terabytes. However, I find it boring! Often times when I solve some issue, I do it with a completely different agenda in mind. </hr> </a> If I upgrade the SSD, I just end up never having to worry about storage again (I keep everything pretty clean, so 1tb is more than enough) and learn nothing. But if I try to solve the issue with a usb drive, now that's interesting. I know Linux's mechanics for mounting a drive, but mostly on paper — I've done them before, but they aren't something that I do often enough to put deeply into my workflow. If I have to use a usb drive, I'll learn about all the steps surrounding it more deeply, so I get a "learning benefit" by trading in effectiveness of the solution, lol. </hr> </a> As I've made clear, I don't have deep knowledge, but let's go through the simple parts that you may want to know, if you didn't already! On windows, new drives appear separately, as new drives. With their own letter and everything. If you get beyond drive Z</code>, your computer explodes. Simple stuff. Linux does this differently! You don't get another /</code> or anything like that — you get to decide where the (usb) drive lives by mounting it. You say to the filesystem: "hey, act like this usb drive is located here". </hr> </a> sudo mount /dev/sda1 /mnt/usb</code></pre> Looks like a pretty simple command! What was most non-obvious to me in it, is the directories passed. "What in the living and dying hell is /dev/sda1</code>?" — that is our usb drive! Well... saying that is a bit misleading. That name is not at all guaranteed and might be different for you, and that's if the drive got recognized to begin with! </hr> </a> So, let's call lsblk</code> in our terminal and look at the output to try to find our drive: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 1 230.5G 0 disk └─sda1 8:1 1 230.5G 0 part /mnt/usb nvme0n1 259:0 0 238.5G 0 disk ├─nvme0n1p1 259:1 0 1000M 0 part /efi └─nvme0n1p2 259:2 0 237.5G 0 part /</code></pre> Don't worry, it's confusing to me too! -1 clue what MAJ:MIN</code> means, and RM</code> is a wonder to me as well. Forget about RO</code>. Anyway, I'm going to focus on the part that's going to be useful to you first. In the NAME</code> column, thingies are shown in a tree structure. nvme0n1</code> is the name of my SSD drive! and sda</code> is the name of the usb disk. Yipee 🥳 </hr> </a> However, there's still this tree structure. This confused me, but now I finally realize what's happening: the items that are branches (with the └</code> before them) are partitions of the above drive. These are what you should be pointing at when trying to specify a drive somewhere, not that parent item. So, what we did so far is the following: inserted the usb drive into some port, executed lsblk</code> and found a drive that isn't our SSD. Then looked at all the partitions (branches) it has (may have more than 1 potentially) and took that as the thing that we'll be calling our usb drive. </hr> </a> That /mnt/usb</code> directory is actually pretty arbitrary! The /mnt</code> directory is a conventional place where you can mount your various drives. It is not the only place however, I believe ext4 (the linux filesystem you're probably using) allows you to mount things anywhere. So, in the /mnt</code> directory I created a directory called usb</code>. Just makes sense to name it that way, you can name it whatever you want! Keep in mind that /mnt</code> is restricted, so you'll have to create usb/</code> with elevated privileges: sudo mkdir /mnt/usb</code></pre> </hr> </a> Because /mnt</code> is restricted, /mnt/usb/</code> is going to be restricted too. Considering that this our lovely personal usb drive, it makes sense to own it. sudo chown username:username /mnt/usb</code></pre> Viola, now the directory is actually ours 🥰. I sure hope you replaced username</code> with your actual username! </hr> </a> After explaining what the directories mean, now sudo mount /dev/sda1 /mnt/usb</code> makes a bit more sense. We finally can start actually using our usb drive, as if it's just a normal directory on our filesystem! </hr> </a> The 61 gigabytes of content I had downloaded, I now started moving to my shiny new drive. Quickly issues started to arise, and my mirror rolled its eyes 🙄 when I said "I told you this would be a learning experience!". Sixty one gigabytes of data is quite a lot! Understandable that it would take some time to move. But it was getting ridiculous! In my very rough count, it took TWO whole minutes to move a single gigabyte. The drive I bought is usb 3.1 so I was flabbergasted, but brushed it off as "damn I guess usbs are that slow still". The last time I needed to use a usb drive not to install linux was back on windows, so I had no recollection of a good transfer speed. However, in an interesting turn of events, this turned out to be a chehov's gun. Yes I am making a cliffhanger in a blog post, what about it >:D </hr> </a> I don't need to move a whole ass 61gb of data often, if at all, so this slow transfer speed seemed to be an okay-ish tradeoff for the extra space I now get. My internet speed will be the bigger bottleneck anyway. After ~4 hours (or so it felt), the moving finally finished. I excitedly went ahead to download more youtube videos, now to the usb drive, rather than my SSD. Exciting! As I download the new videos, I decide to watch one I already have downloaded, at the same time. After a while, I notice a horrifying fact... There's buffering now! What the fuck? The whole reason I download all youtube videos I watch is to avoid buffering. </hr> </a> So I guess write speed is a bottleneck in the place that matters more: my watching experience... 😭 Well, let's think about this: currently I have 6 videos downloading. All of them are written to the usb. I'm not sure how read vs write conflict, but I'm sure writing that much introduces some congestion. I guess I just have to download videos while not watching them at the same time! That's kinda bad, but I can easily get used to it, no big deal. After my downloads all finished, I decided to test by watching another downloaded youtube video. Surely now the buffering is gone; there's no writes coming into the usb! Oh my god... I am horrified to discover that I still have buffering... It's maybe not as bad, but this thought may just be powered entirely by bias. Let's start another chehov's gun here, and talk about something that seems unrelated. </hr> </a> I despise when hardware, like my laptop, earphones, headphones, speakers, power switches, phones, have some lights on them. The reason for them to exist is to tell you information, like the charge percentage, connection state, on / off position. However, I'm autistic! Those random lights can be a real bother when I'm trying to sleep, and yet my room lights up. When I first inserted my new usb drive, I was horrified to find out that it has a light on it too... I guess I should've checked for that, but the design of the usb drive had nothing to suggest a light; matter of fact, the light is inside of the usb, in a sorta awkward fashion. I would never expect that I would not only like this light, but also find it useful. I eventually naturally noticed that it stays solid some times, and blinks other times. This has to mean something, right? Turns out that if it's blinking, some io operations are being done with the usb drive; if it's solid, none are happening. Nope, surprisingly enough I didn't read the manual on the usb drive (HS-USB-M220P/256G/U3</code>); I discovered this behavior via another way: I remembered the sync</code> command on linux. It flushes the read/write data to make sure it reaches its destination, finalizing all the read-write caches. As I was watching that youtube video I downloaded, with no other downloads happening at the moment, the light was flashing. Fair enough, it's reading from the drive to let me watch the current video. So I close it, but still see it flashing even after waiting for a couple of seconds. I do sync</code> and eventually the flashing goes away 🤯 So maybe, the weird buffering issue happened because of write caches staying for too long? Nope. Cool guess though. We handled chehov's gun #2, but didn't actually move to the solution. Let's check up on chehov's gun #1! What about those super slow write speeds anyway? </hr> </a> After not being to fix this buffering issue, it made me think: I bought my laptop 2-3 years ago, for a pretty solid price, new. How the fuck would it only have usb 2.0 ports? That sure sounds unlikely! So this time I do google the specs of my laptop</a>. Europe! I do have a usb 3.x port! You might reasonably ask "how the hell do you not know that already?" Good question! I noticed a long time ago that usb 3.x ports are colored blue, to make them easy to tell apart from usb 2.0. This seemed so consistent, that I simply ignored one of my ports as a possible solution. I have nothing to lose by trying to prove myself wrong, so I insert the usb into the one port I haven't tried, mount it, and try moving a big ass video file, that would usually take 2+ minutes to move. Well holy shit! It's moving waaayyy faster! Yes! This is definitely a 3.x port! (however it is still massively slower than what I expected out of 3.x). aha! chehov's gun #1 solved everything!</a></h1> Right?.. Wrong 😭 Sure, moving stuff is now way faster, and I got a sense of regret due to the 4 hours of useless extra waiting, but fascinatingly enough, I still had weird pauses in mpv. And as always, A™ Configuration™ Option™ saved the day. Turns out if you set cache=yes</code> in your mpv config file, it will automatically prefetch the video you're watching wayyyy forwards, completely eliminating the pauses (that I call buffering), even if you're also downloading like 6 videos at the same time. God I love mpv 😩 /srs Yipee 🥳 would be better to know about this prior, wouldn't it?</a></h1> Nope, not really! I decided to buy a usb drive specifically to run myself into issues like all of these, and learn things by solving them. I succeeded in that exact goal SPECTACULARLY. The decision went exactly according to plan. First, I now know that I have a usb 3.x port, and that the other two are usb 2.0. Then, for once I like a light in my hardware! Thankfully, it turns off when the laptop goes to sleep (thank god). I like it now because of how nice it feels to have the information of io operations given to me at all times. If I notice the light blinking at a time where I don't expect, it's something that I can look into / investigate, rather than not know at all. If you saw my window manager bar, you'd say "yep checks out". (I have like a billion widgets) Knowing the io operation information also made me accept a lesson I always thought to be unecessary bullshit. Since childhood, back on windows, people around me always said to right click the usb drive and click "safe remove". I did it at first, of course, but after a while I noticed that it's just completely useless. Does seemingly nothing. Now that I actually see the io operations by the light, I won't just pull out the usb all willy-nilly: it's clear that I would be fucking over something. So what I now do is first sync</code>, and then sudo umount /mnt/usb</code>. For a shortcut that does both at the same time: sudo eject /mnt/usb</code>. conclusion</a></h1> I sure learnt a lot! And still have the opportunity to learn more: experimenting with the drive's filesystem, figuring out an auto-mounting solution (requiring sudo every time will, I'm sure, get annoying), or maybe another problem I don't yet realize I have! And all these reasons are why it's sometimes reasonable to go for the worse solution, if you feel that it will lead you to something more important! :3 magazines Axlefublr — Sun, 03 Nov 2024 00:00:00 +0000 I came up with a concept that completely revolutionized a lot of my workflow. I introduce to you: magazines™! the basics</a></h1> Each magazine is just a normal file that has a one letter file name, from a to z, from A to Z, and from 1 to 9. All magazines are located in a single directory called magazines</code>. The name doesn't really have meaning, I just happened to be obsessed with guns at the time of coming up the concept </blockquote> I have different actions I can do on any magazine. An "action" is just some shell function that interacts with a file in some way. And finally, I have chord mappings that make me pick an action, and then a magazine to act on. All the magazines use either a letter or a digit for their filenames, to mimic the hotkeys I use to choose them. actions</a></h1> All action picking hotkeys use left shift + a left side key. This is because when typing, I will always use the right shift for left side keys, so I get to have very accessible hotkeys specifically for magazine actions. After I press the action hotkey, I press a letter (or digit) key, to pick the magazine I want to execute the action on. This is a pretty simple concept! But it's so flexible specifically because it's so simple. Considering that all actions just act on some filepath, let's go over the actions I can do! use rofi</code> to type in a line of text, and overwrite a file with that text (lshift+alt+s</kbd>)</li> 1, but append the line rather than overwrite with it (lshift+s</kbd>)</li> copy the text in a file to my clipboard (lshift+c</kbd>)</li> truncate the file (remove its contents, but don't delete the actual file) (lshift+r</kbd>)</li> 3 + 4 — this is basically a "cut" action (lshift+alt+c</kbd>)</li> take the contents of my clipboard, and overwrite a file with them (lshift+alt+v</kbd>)</li> 6, but append the contents rather than overwrite with them (lshift+v</kbd>)</li> use rofi</code> to pick a line from a file to remove and copy to my clipboard (or, to cut to my clipboard basically) (lshift+f</kbd>)</li> use rofi</code> to pick a line from a file to copy to my clipboard (like 8, but doesn't remove the line) (lshift+alt+f</kbd>)</li> open a floating terminal, in which the file is opened in helix, to get the full power of my editor in a fast way (lshift+d</kbd>)</li> </ol> Further in the gist I'll refer to actions by their shortened name, with a superscript number next to it, that specifies the index in this list. </blockquote> autocommitting</a></h1> All actions that modify a file, also commit it with git — the magazines</code> directory is a git repo. This way, I have a very easily traversable history, that doubles as a backup. As long as something has been in a magazine, I will be able to restore it if necessary. Commits are done automatically by all actions that modify a file; however I can still modify magazines elsehow. I have hotkeys in helix to open each magazine in the already existing editor session (different from the 10th action, because I'm not opening a new floating terminal window). When editing the magazines like this, it's not an action so can't be a convenient trigger for an autocommit. That's why there's an 11th action that just commits a magazine. All the leftover changes that still didn't get committed, are collected together into a single commit, daily. So at the absolute worst, I have a day old backup for all magazines. most important magazines</a></h1> Let me go through some of my actively used magazines and their purpose, to explain how this system helps me keep track of things in an easy way. magazine r</a></h2> ...stores all things I want to read. "read" is used pretty loosely here, as the file contains a bunch of different stuff I basically want to get to, while not necessarily being a "task" that I can do. Here's part of what it contains currently: !# gh cli (gh-issue-develop) !& Hugo # pandoc # string-replace $ loago-based workflow $ magazines % how to remove background in krita % can you "close all other windows" to close the main window from an overlay window in kitty? & qalculate & zbarimg pcre or whatever regex the sliding window technique https://matklad.github.io/2021/07/09/inline-in-rust.html https://www.howtogeek.com/how-to-see-beautiful-git-project-stats-in-your-terminal/</code></pre> This seems like a hotpot but it's pretty intentional. #</code> marks docs that I want to read (with the part I left off on written down in ()</code>), $</code> is gists / blog posts that I want to write (magazines</code> is this one!!), &</code> is for programs that I want to discover, %</code> is for questions I want to discover, figure out, or take in. </hr> </a> The two questions I have there seem simple, but they may stay there for a while because they're more loaded questions than they seem. I'm sure there's more than a single way to remove the background in krita, with each being useful in a different situation — I'd want to focus on learning this properly. Even more the case with kitty</a> — trying to solve this question might move me to come up with a different window managing concept that I'll then spend three more hours on. Never underestimate a question, especially if you're autistic like me. </hr> </a> I usually use the append² action for this magazine. With vimium c</a>, I can copy links I see on the screen to my clipboard, using my keyboard. The various rogue links you see without a section header are usually added by copying a link that way, and using the append clipboard⁷ action. Sectioning things is pretty nice, but has an additional benefit that I haven't yet made clear. The commit¹¹ action has extra functionality to it: I can pick filepaths that are automatically sorted. The section headers intentionally use ascii symbols that go before letters, so that they would appear first in the file after it gets automtically sorted. Going in and editing the code for the commit action every time I want to autosort another magazine would go against my principles. This is why I use another magazine to solve this! magazine O</a></h2> ...contains all the filepaths that I want to automatically sort: ~/.local/share/magazine/l ~/.local/share/magazine/r</code></pre> So if I decide to autosort another magazine on commit, I can just add its filepath there! :D This autosort behavior explains the reasoning behind !</code> before some section headers: !</code> is the first printable character in ascii, excepting space, with its decimal index being 33. So it's guaranteed to come first. I use it for reading tasks that I want to get to first, before any other ones. magazine P</a></h2> ...is similar in concept to O</code>: filepaths listed in magazine P</code> are automatically made unique. If a magazine path is listed in magazine P</code>, there will never be duplicate lines in the former. I could opt to join O</code> and P</code>, but I might want to sort a file without deduplicating lines, and may want to deduplicate lines without sorting (which you can achieve with this monstrosity: awk '!seen[$0]++'</code>), so I keep them separate. </hr> </a> The above examples are magazines that are fairly dynamic and moving, but there's use in magazines that are fairly static, and are made mostly to access the information faster, than necessarily change it often. magazine u</a></h2> ...contains a bunch of cool looking special symbols and nerd font symbols, that I may use in the future. Here's a small chunk of it: 󱞭 󱞯 󱞱 󱞳 󱞵 󱞷 󱞹 󱞻 󱞡 󱞣 󱞥 󱞧 󱞩 󱞫 󱞽     󰁕      ⮌ ⮍ ⮎ ⮏  ← 󰹹  󰒟 󰚪 󰘲 󰕍 󰓦  ↪ ➜ 󰒊 ▶ </code></pre> The only action I may conceivably do with this one, is to edit¹⁰ it. And even then, usually from an already existing helix instance. The benefit is yet still huge, as it's very easy to get to this file to add another cool unicode symbol. magazine o</a></h2> ...is the opposite of static — it stores the command output of the last command I ran in my rofi command runner. Usually, the output of my rofi command runner is shown in a notification that stays for 3 seconds. That's plenty of time for the vast majority of usecases, but I may want to look at it for longer. Blammo — edit¹⁰ action. That's fairly convenient as is already, but the real power lies in the copy³ action. Any time I execute a command, I can choose to copy its output, if I need it. So, I don't have to preemtively plan to pipe the output into xclip</code>, and don't have to rerun the command once I realize I want to pipe it into xclip</code>. I just use the copy³ action. </hr> </a> Another power I get for free, is that I can choose a line to copy⁹ from the command output. I didn't consider this as something I'd want to do with command output — it wasn't forethought. It just so happened I needed this action for something else (magazine F</code> that stores cool fonts) and now the action is integrated into the magazine framework. So with magazine o</code>, and many other ones, I end up having editing flexibility that I didn't plan for that magazine specifically. It's a big part for why this system has been so successful for me. special-casing</a></h1> I create all the hotkeys for all the actions, and all magazines, myself. There are like 900 or so lines of yaml to make them all using xremap. Because I don't have some complicated system to make the mappings, nothing is stopping me from making some action for some magazine behave slightly differently, to be more useful for that magazine. magazine l</a></h2> ...is my "linker". It contains all the links I want to store in this format: !general my youtube channel — https://www.youtube.com/@Axlefublr/streams blog reasons I still love fish shell — https://jvns.ca/blog/2024/09/12/reasons-i--still--love-fish/ doc ankiconnect — https://foosoft.net/projects/anki-connect/ general phind — https://www.phind.com gist why I hate kitty — https://gist.github.com/Axlefublr/260f653c25c34c3ed6147a6638fc6512 mat gun sounds — https://samplefocus.com/tag/gun meme I have done nothing but teleport bread for three days. — https://www.youtube.com/watch?v=NE1-dKc6R_I music hatchetsaw, hauntgat, fleshwound — country side massacre — https://www.youtube.com/watch?v=H4Hw-ARuEa4 plug nvim harp-nvim — https://github.com/Axlefublr/harp-nvim proj Axlefublr/helix — https://github.com/Axlefublr/helix</code></pre> First goes a "header": general</code> / blog</code> / music</code> / etc. Then the title of the link. Then a —</code> (long dash, U+2014). Then the actual link. I used to use the append² action for this in the past, but found it annoying to have to put in a long dash and paste in the link every time, considering that it's the only thing I'd want to do anyway. I created a "subaction" meant to be the append² action replacement, but only for magazine l</code>. The only difference, is that after I type in the input (link title), it appends a —</code> to it and the link (which is in my clipboard), and then adds it into the file. That makes it really non-laborious to add in new links! As well as showcase how flexible magazines are, considering that I was able to make a custom action for something like this. </hr> </a> Now, there's a reason I want a specific format here to begin with. I don't actually open this file directly that often. Magazine l</code> is used as a "data file". All the links are stored in it because I have a global hotkey that parses through them all, lets me search by title, and then either opens the link or copies it to my clipboard. So, sometimes magazines are the behavior, other times they're an interface to interact with a data file conveniently, so that it could be used by something else. magazine e</a></h2> 's idea is basically the exact same: ¡ a1 reversed exclamation ⁷ 2077 top superscript 7 seven ↕ 2195 arrow down & up 🐄 1f404 cow 🔇 1f507 muted speaker 🤢 1f922 vomit</code></pre> Easier automatic adder, that takes the symbol from my clipboard, figures out each character's unicode (try printf %x \'🐄</code>), and asks me for a title. Then a hotkey that lets me search by all of that, to copy just the symbol to my clipboard, so I could paste it wherever I need. That's about it when it comes to the explanation of the idea! Hope you got motivated to implement something like this, or better yet — something that makes even more sense for you. Right now I'm going to continue explaining a bunch of my other magazines and what I use them for, to maybe help you get ideas. etc etc</a></h1> Out of these magazines: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789[];',./{}:"<>?</code>, I'm actively using these: acdefijklmopqrsuvwxACDEFHIJKLOPQRSTUVWXYZ134[];:</code>. Yes, really, that many! I'm thinking of possibly adding hotkeys with alt</kbd> in the future, once I run out of magazines. Then ctrl</kbd>, then shift+alt</kbd>, then... etc. That would in theory increase those ~900 lines of yaml to be like, three million! Oh well :> a</kbd> stores "all the possible things I can do" — helpful to take a step back, breathe, and calmly decide what next to do, rather than hurrily and anxiously jump around in my mind. c</kbd> stores copypastas I want to be easily accessible. Here's one of them: «when making australia God said "only a spiderful" but then pulled out a comically large spider». d</kbd> diary that gets automatically emptied every day. Because all remaining changes get automatically committed at the end of the day, I have access to all of my past's diaries, without it cluttering up in one ginormous file. I don't really ever read my diaries from that past, that's why. f</kbd> similar to a</kbd>, but I store specifically the "next" things I want to do. Here's what it has now: ff: !' is ctrl+l, +!' focuses page by probably clicking <c>, cda, cdb, cdab, codeblock, code, anki in not subheaders qalculate life drain anki plugin https://ankiweb.net/shared/info/715575551 css flex blog https://ankiweb.net/shared/info/206062158 anki searching</code></pre> Very helpful with keeping me on track! k</kbd> stores links to youtube videos I want to download, K</kbd> to longform videos, i</kbd> to asmr videos. I have a script that takes a couple (dynamically settable) links from one of these three files, and starts downloading them, removing them from the magazine. j</kbd> is special-cased to instead be ~/prog/dotfiles/project.txt</code>. project.txt</code> is a file that gets automatically created for all of my projects, and I use it to organize thoughts of what I want to do in a given project. J</kbd> is special-cased to let me choose a project.txt</code> to act on. Reason why j</kbd> is made more accessible, is that I really like to configure so I interact with the dotfiles project file the most frequently. m</kbd> stores long-term project ideas that I'll definitely do Eventually™. p</kbd> my proxy's information. I can quickly go in and copy the address, for example. q</kbd> my hardware specs. Even includes the specs of my physical body, lol. v</kbd> important events that I want to be reminded of yearly. I have a script that runs every day to check this file, and tells me stuff like "3 years ago: started programming". Here's the format: 21.09.01 — started programming 22.09.24 — started using vim 23.08.06 — installed EndeavorOS 24.02.21 — she/they 24.08.18 — switched to helix</code></pre> V</kbd> is the same thing with the same format, except it's not checked daily; it's for event dates I want to have access to, but don't care to be reminded of. 23.07.26 - installed Debian 24.02.22 - switched to pure neovim 24.03.11 - 16gb ram</code></pre> Q</kbd> is also similar to v</kbd>, but doesn't specify a year — mostly for storing birthdays and getting reminders of them. For reminders of things that will happen once, or monthly, or yearly (mostly payments and meetings), I made a python script that parses T</kbd>. w</kbd> is the short-term shopping list, and W</kbd> is the long-term shopping list. These make more sense once you realize I have a telegram bot that lets me easily interact with magazines from my phone. x</kbd> contains today's "habit tasks". My daily tasks alternate: one side is stored in [</kbd> and the other in ]</kbd>; each of them happens every other day. One thing I have in [</kbd> is to read through D</kbd>, which stores words / mindsets that I want to implement into myself, and so repeat every two days: split the scary into "not very" laborious stellar :o :O ・>・</code></pre> Z</kbd> contains package names I installed with pacman</code> (meaning, from one of the arch repos), X</kbd> for those installed from the AUR. In my system setup script, both of these magazines are used to install all packages I want. C</kbd> stores packages that I want to be deleted the next time I update. This makes more sense to exist once you realize the workflow of filtering⁸ Z</kbd> or X</kbd>, and then appending the clipboard⁷ to C</kbd>. E</kbd> is actually a big ass list of all unicodes for my other, slower but more complete unicode symbol picker. L</kbd> contains commands to always be in my rofi command runner history, H</kbd> for the dynamically generated history. R</kbd> repository paths, that should be automatically git push</code>ed daily. U</kbd> a big ass list of words I use for ttyper</code>, to practice touch typing. Which I never do anymore, but still. Y</kbd> my youtube channel subscriptions, because I don't trust google to keep that information. 1</kbd> consistently used as "store something short-term". 3</kbd> a bunch of things make "notifications" into here, like my various event notifiers, for example. 4</kbd> github notifications go here. ;</kbd> by the time I finished writing this gist, the $</code> writing tasks from r</kbd> moved here. :</kbd> similarly, %</code> "processing" tasks from r</kbd>. elegant fish shell booleans Axlefublr — Thu, 24 Oct 2024 00:00:00 +0000 I recently finally figured out how booleans work in fish shell, and turns out they're very elegant! You can use set</code> to set variables to values; you can set them to true</code> or false</code> too. If your editor supports fish shell as a language, it will probably highlight them as booleans. What are they? Some special types, or special syntax introduced by the shell? Not at all actually, they're just strings, like asdf</code> and the</code> would be. </hr> </a> You usually use test</code> to check for various common equality comparisons, in shell scripting. if test $var = 'thingy' echo yeppies end</code></pre> If the string in variable var</code> is equal to thingy</code>, output yeppies</code>. </hr> </a> Let's examine more closely why we need test</code> here to begin with. What if</code> does, is take in arguments, call those arguments as a command, and execute the inner block of code if the command's exitcode is 0. test $var = 'thingy'</code> are the arguments to the if</code> command. If test</code> executes successfully (meaning $status</code> is 0 after it exits), if</code> will execute the code block, which is echo yeppies</code> What this means is that both test</code> and if</code> are not that special. They're just commands doing command stuff. So you can use any command in an if</code>, to check for its exitcode: if rg 'struct' args.rs echo yeppies end</code></pre> If there is the word struct</code> in the file args.rs</code>, output yeppies</code>. I'm saying all this to highlight: if</code> just wants to execute a command as its condition, that's it. </hr> </a> You can even store the command in a variable: set -l command rg 'struct' args.rs if $command echo yeppies end</code></pre> The variable $command</code>, will expand to be rg 'struct' args.rs</code>, so this is basically equivalent to the codeblock above, where we don't use a variable. </hr> </a> Coming back to booleans: set -l var1 true set -l var2 false if test $var1 echo yeppies end if test $var2 echo yeppies end</code></pre> Despite true</code> and false</code> looking colorful, and therefore seeming "special", in your editor, they are actually both just strings, so both if statements here will execute their codeblock. </hr> </a> I always thought, for some reason, that false</code> will evaluate to, well, false in test</code>, but now that I think about it, why would it? The real gold lies in something interesting: both true</code> and false</code> are also commands. Fish shell built in commands. true</code> always returns with exitcode 0, false</code> always returns with exitcode 1. So by setting variables to (completely normal strings) true</code> or false</code>, you also happen to set those variables to commands that can be executed in if</code> conditionals. set -l condition true if $condition echo yeppies end set condition false if $condition echo yeppies end</code></pre> Will essentially expand to: if true echo yeppies end if false echo yeppies end</code></pre> It's much more clear this way, why true</code> and false</code> seem special! It's entirely just because they also happen to be commands that you can call to get your wanted exitcode, not because fish shell uses them as special syntax. why even helix? Axlefublr — Mon, 21 Oct 2024 00:00:00 +0000 I've been using neovim for around two years. I've rewritten my config three times: for the first time, when I switched to astronvim, and when I switched back from astronvim. At the most recent point, my config was 5000 lines long. I've gotten into the habit of reading nvim help pages in their entirety, for fun. I have also written s</a>e</a>v</a>e</a>n</a>!</a>!</a> plugins. And usually spent multiple hours every day configuring nvim. I'm glazing myself here to point out: I have obviously given nvim a good try; matter of fact the try was unreasonably good! And the reason why I switched off nvim is not due to the lack of knowledge about nvim. </hr> </a> Considering my two</a> other</a> blog posts, this one should be called "why I hate nvim", but I don't actually hate it! I just realize that helix is simply the better option. I've been wanting a brighter future than nvim, for a long time. And while I did look at helix, there was something that stopped me from considering actually switching to it. I'm sure you've heard of this stance, or even maybe have it yourself: "helix has no plugins, so I'll just wait for it to get them, and then I'll switch". Fair enough! That was my idea too! However, I'm autistic, so switching to things is a whole ordeal, usually taking me multiple consecutive days, and taking a lot of time, effort, and energy. Doesn't really make sense to wait for the plugin system, to then overwhelm myself all at once, does it? So I decided to do it the smart way. the plan</a></h1> First, I go on and fully discover helix. Learn the editing model, the bindings; configure it to be fairly usable, go through the entire documentation</a> to not miss anyting. With this basis, I effectively split the overwhelm into two parts, making it more manageable. So that when the plugin system comes, I can actually switch. Yes! My idea was to stick with nvim still, but think about the future in this way. I failed spectacularly... Or did helix succeed that much? Let me elaborate on why I switched to helix so soon, despite intending not to! the editing model</a></h1> Helix's "selection->action" model is ultimately the biggest reason for why I switched. Despite being so used to vim's "action->selection" model, it took me 1-3 days to get used to helix's one. I believe it's because it feels that natural! The way my brain works is something like this: "uhhhh right so this piece of text"</li> "uhhhhh facken let's do this"</li> </ol> rather than: "uhhhhh soooo let's do this ig"</li> "with uhhhhh this text"</li> </ol> </hr> </a> It's fairly often that I know subconsciously what I wanna do, and actively "discover" what that something actually is. Because of that, I may take ridiculously long pauses between my keystrokes to think. Nvim has this incredibly annoying default, where your action+selection key sequences are quick time events. I'm serious! You have to execute the whole action in some amount of time after pressing the "operator" — otherwise it will time out. You can of course disable this (via :h 'timeoutlen'</code>), but this is just the start of the pattern of bad defaults in nvim. For now I will just state that since this is a default, other nvim functionality (as well as plugins), will often be designed having this behavior in mind. In short, nvim penalizes pauses. </hr> </a> Coming back to the example above, nvim makes you decide on an action first, and the selection second; right after you just decided on an action, not encouraging pauses, it makes you decide the selection too. "That's kinda rough when you put it that way, but it's not that bad, right?" — I'll make my argument less strawmanny and still showcase how it's actually really terrible. Let's do this very very common thing in nvim and fix a default: we will disable the key timeout. We'll claim that "well yes OBVIOUSLY you change that" and transform an individual named Bob into the brother of our parent. We still have a pretty glaring issue with the editing model as a whole, even with key timeout not being an issue. Whether or not we'll even be able to make the selection is not a guarantee! "First you select an action to do and then the area of text it acts on" is not the full story at all. vim's actual editing model</a></h2> Especially without plugins to help (notice, not solve), you will often times not be able to select the text area that you actually want. The more realistic model of vim is: Place your cursor in a position from which you'll be able to make the selection motion later</li> Decide on what you want to do</li> Think about the selection again, now actually making it</li> </ol> It's a lie to say that vim has an action->selection model, because you first need to figure out if your selection will even work! And because of things like dot repeat, and efficiency (generally doing an action via action->selection is less keystrokes than the visual mode (selection->action) equivalent, in nvim), actively picking to always use visual mode first is a known anti-pattern! Think of any vim tutorial: things like "you should use ciw</code> instead of viwc</code> 🤓" are always (validly) pointed out. core philosophy as a solution</a></h1> In helix, half the time you don't even need to think about how to make the selection, because you already made it just by naturally moving around. The w</code>, e</code>, b</code> word motions that you already know and love now also select the word. This is useful because in helix, you always operate on a selection. Matter of fact, your cursor is just a 1 column wide selection! As I've been writing this blog post, I've been moving around using the word motions — they're pretty natural for moving around in literal text. Another thing that's very natural to want to do in literal text is to delete / change words. This combines nicely: I move to some word, and it also happens to become my target. Often times, I only need to press a single key to do the action that I decide to do. The reason why you'd usually want to use ciw</code> rather than ce</code> in vim, is due to precision. With the former, you can act on a word no matter what, and so by spending an extra keypress, you can allow yourself to spend less mental effort. Interesting tradeoff! It only really makes sense because to see what you're going to capture with a motion, you need to actively think. What if your editor thought for you? </hr> </a> This is effectively the greatest strength of helix: rather than having to spend mental cpu cycles to figure out what you'd match with a certain motion, you already can clearly see what you'd match, always. Rather than thinking "hmmmm how do I change this word?", you think "I want to act on this area... oh wait! it's already selected! I guess I just c</code> then!". This seemingly small difference ends up merging together to form a much nicer editor experience, especially considering that the entire editor is designed around it. "normal" semantics</a></h1> Something that took me a bit to get, is the semantic of normal mode in helix. I can put it to words most precisely like this: In normal mode, as you move, you replace your selection by every next motion. In select mode, you extend your selection by every next motion. Pretty straightforward, isn't it! Might take some time to get used to, but ultimately it's really nice. Let me present another example of how this model aids you, without you needing to put in extra effort for extra benefit. The f</code>/F</code>/t</code>/T</code> motions replace your selection too! When you f</code> towards something, you make a selection from your current cursor position to the character that you aimed for. You may use f</code> just to move and ignore the selection it makes, or you can use f</code> to select towards something to then delete it, for example. Regardless of which action you decide to do, you can make the motion in the exact same way. built in "plugins"</a></h1> Helix has the equivalents of telescope</a>, nvim-surround</a>, whichkey</a>, lspconfig</a>, easymotion</a>, CamelCaseMotion</a>, conform.nvim</a> built in. That's pretty nice! But ultimately things being built in is just nice, not really an argument towards an editor. After all, all of the above are really known plugins in the nvim community, so it's very likely a nvim user uses some, or all of them. Right? That point of view misses something. Neovim plugins are inherently limited by the nvim API. They can only be as good as nvim allows them to be. Some of them may employ some hacks, or less than pretty implementation details that end up making a plugin feel like a plugin. Something that was tacked onto a foundation that didn't think ahead to work nicely with that plugin's behavior. As someone who made 7 plugins, I encountered this fact very closely. telescope</a></h2> An amazing plugin, fwiw. Very extendable, configurable, powerful. However, it does so much while built on top of neovim, that it's noticeable in usage. When I launch telescope, I can distinctly see two rendering stages: first, the window appears. Second, it's filled with text. The two stages happen slowly enough where I can clearly notice them, and it's always been jarring to me. I've since tried to switch off telescope, by discovering fzf-lua</a>, but turns out it's even slower in terms of the UI updates (because it uses terminal mode). On the opposite hand, helix's "telescope" is built in, and when you press the hotkey to open it, all of the UI happens at once. It opens, rather than loads in, is how I can describe it. And god does that feel incredible! whichkey</a></h2> Neovim's whichkey uses key timeout to reveal itself, which I've already explained being quite uncomfortable to use. But without key timeout, you get no whichkey. This is not a point against folke</code>, it's a point against a plugin that is better served by being built in. And omg, it sure is, in helix! Immediately as you press a key that has submappings, you get shown a whichkey menu, on the right side of the screen. Because there's no key timeout, you can look at it for as long as you want to! This is how I was able to discover a large part of helix. Generally I use anki</code> to memorize all keybinds, but with a nice interface to teach me, there was far less need to do so. Because the mapping system is designed having this menu in mind, you create all of your mappings in a hierarchical fashion. So, rather than mapping mf</code> to something, you map f</code> in section m</code> to something. Nvim's whichkey had to create this system for itself. nicer registers</a></h3> Another neat thing it does, that completely solves an issue nvim otherwise has, is that when you access a register (via "</code> by default), it shows you the contents of filled registers in that same whichkey menu! In nvim, you use :reg</code> to look at a register's contents. But you only ever need to look at a register's contents right before using it in some way, and so helix does exactly that! I was never a fan of the whichkey idea overall, but helix's implementation was very helpful and improved my opinion a bit :3 Ultimately still, it's a bit too much UI for me to see jump around, so I removed it once I memorized every mapping. In my fork</a>, I added an option to disable the whichkey menu, but keep it for registers, so that's what I've been using. surround</a></h2> Because nvim text objects are actually just visual selections in disguise, using text objects is often jumpy and hard to look at. When you combine that with nvim-surround, which uses even more janky movement + change approaches, the experience ends up looking very "pluginy". The helix built-in surrounding mechanism doesn't have to work within such restrictive rules, as it's built into the system to begin with. There's something really elegant and powerful it lets you do, thanks to that! Say you're writing markdown, and want to make a word bold, retroactively. In nvim, you would do ysiw*ysiw*</code>. You almost could ysiw*.</code>, but I believe it moves your cursor onto one of the *</code>, making you first move before being able to dot repeat. So basically, that's kinda cumbersome. And that's just a situation where you can use the same motion twice; that's not always the case. For example, it isn't the case if you wanted to surround a word</code> in such a way, that you would get: { ['word'] }</code>. In nvim, this is kind of a pain, because you keep needing to use a different text object every time: ysiw'ysa']ysa] ysa }</code>. Even if we assume you use a plugin that makes that last ysa] ysa }</code> into a ysa]{</code> (targets.vim</a>, I think?), we still get left with: ysiw'ysa']ysa]{</code>. First, it's an obscene amount of characters to press. But more importantly, you use THREE different text objects here, and one of them uses i</code> rather than a</code>. Doing this has always been quite a pain for me, as you need to think about what you're doing with considerable amount of focus. </hr> </a> How does this work in helix? Remember that "motions replace your selection" thing? What if I told you surrounding did this too? Genious! Of course it would! Due to this convenient consistency, executing the two examples I just gave is very simple. The first one, considering that you already selected the word, is: ms*ms*</code>. After the first surround, your selection updates to contain the new characters you just added. So you don't need to "fix" your selection or anything! You unfortunately can't dot repeat that second ms*</code> in helix yet, which is quite annoying :c In nvim it wasn't that big of a deal because you had to fix your position anyway, but it would be way nicer to have in helix because you don't need to fix the selection. The second example is just fantastic, especially in comparison: ms'ms[ms ms{</code>. All you need to do is just keep saying what you want to surround with. Not having to fix your position, or use a different text object, REALLY helps here! I can do this blindly without really needing to focus much, so it's quite a big win. autopairs</a></h2> Not much to say about this one, it just works! You can define what your autopairs are globally, and then also define them per-language, in a very obvious configuration format. Very possible that I just picked a wrong plugin, out of the million that exist, but in neovim adding an autopair was a chore, that also ended up working differently from all the other autopairs already enabled by default, in a jarring way. lsp</a></h2> Oh my FUCKING god do I despise neovim's lsp integration. Somehow despite all of my experience and knowledge, when it comes to the editor, I still see lsp configuration as half magic. Fucking 5 or so different plugins doing god knows what in magicky ways, requiring you to do a lot of guesswork to configure in any non-standard way (that lsps sometimes require (rust-analyzer)). With this structure, hanging on by a thread, it still takes up like 50 or so milliseconds off your startup time, which is pretty horrendous. You then may spend a lot of effort on optimizing that startup time, too. Which is a craft of its own... I forgot to mention this, but helix starts instantly. If you get all the neovim plugins that "exist" in helix, and lazy load them properly, neovim will still take longer to put you into a buffer, than helix will. You get everything, while not sacrificing speed. And the lsp integration is really simple and lovely. In your languages.toml</code>, you define which lsps you want to use (you can just specify multiple of them per-language if you want!) and what arguments they should be given to start properly. That's in theory, at least. In practice it's probably already done for you by helix contributors. So all you need to do is install the lsp so it's in your $PATH</code>, and blammo — the lsp just works. I'll repeat that: in the general case, to get an lsp to work, you just install it. Often times you won't even really need to configure it. Formatting is similarly simple: you define how to call it (if it's not already done for you), and then can use :fmt</code> or the auto-format option (configured globally and per language, also). There's no non-lsp diagnostic sources like in none-ls or nvim-lint, unfortunately. But it's a tradeoff I'm willing to make, because I only lost fish shell diagnostics, which aren't that important to me anyway. I'm sure it'll get added in eventually, though! registers part 2</a></h1> Let's go back to registers for a bit. The way that helix handles them is what initially made me consider switching to begin with. In nvim, when you yank into a named ([a-z]</code>) register, you also yank into the default register ("</code>). I always found this annoying! Imagine a situation where you yanked something, and are travelling through the file to paste it elsewhere. As you travel, you notice another piece of text that you want to also take with you. What do you do in this situation? Correct, you eat sand and annoyingly come back for it later. Or use my plugin that I didn't publish. You might present uppercase registers ([A-Z]</code>) as a solution, but appending, rather than overwriting a register doesn't necessarily solve the problem. If the important yank you made is a characterwise yank, appending to it most likely isn't what you want at all. Even if both the important yank 1 and important yank 2 are linewise, there's no guarantee that they are related; you might want to paste them separately. Separating them after the fact seems like an annoying workaround. And let's not forget: you yanked to the default register. So you can't even append to it anyway. And you can't retroactively move it into another register, without coming back and reyanking, or without using my plugin</a> that I did publish. All of this hassle because yanking, even to a named register, still touches your default register. A non-unfuckable situation that I ran into often (enough to have made to plugins to work around it). In helix, it obviously just yanks to the register you specified. Duh! You specified a register, that register should be used. Pretty straightforward! Now that same situation is colored in a different light: You yank something important, then find another thing you want to yank. You just select a register and continue on! :D And as you collect these important yanks, when you access yet another register, helix will tell you which registers you're already using, implying what the free ones are. So (if you pay attention) you won't even accidentally overwrite an important yank! </hr> </a> Using registers is always an active decision for me. Because of this, it's common that I yank something, and then think "wait nevermind, I actually want this in register x</code>". This "nevermind" thing happens most commonly when my current default register contents aren't important. In neovim, if you "misyank" something, you then need to re-specify the area you targeted. yiw</code> then "whoops" then "xyiw</code>. Get more and more annoying, the more complex text objects you use. Even if you used visual mode for your selection, you can't just reyank: the selection is gone, and you have to press gv</code> to restore it. In helix, after you yank something, you can re-yank without any such hassle. y</code> "whoops" "xy</code>. That's it. The selection actually staying like that is a common "omg that's so nice" exclaim I do to myself, about helix. But there are places where, at least at first, it's just really weird! </hr> </a> Remember how your cursor is just a single-width selection? Helix stays consistent to the idea of selections mattering more than your cursor in this interesting way: By default, a</code> appends after your selection, and i</code> prepends before your selection. Yes, really! Not your cursor! This means that if you have word</code> selected, and your cursor is at wor█</code>, when you press i</code>, you will start inserting here: |word</code>, rather than here: wor|d</code>. Same case with a</code>, just in the opposite direction. "Ok that's just ridiculous" you might say, and at first I agreed with you! While I did, I remapped a</code> and i</code> to get the behavior we both expect: a = ['collapse_selection', 'append_mode'] i = ['collapse_selection', 'insert_mode']</code></pre> But after using helix for some time, I actually removed these bindings! Helix is very consistent with acting on selections specifically, and when you want to act on a cursor, it expects you to press ;</code> first, to collapse selections. Having a</code> and i</code> fall out of this rule became annoying, rather than helpful, as I got used to pressing ;</code> when I need to. But aside from consistency, turns out it's just kinda nice! </hr> </a> Say you're writing a sentence, and as you move through it, you got some word selected. You can pick whether you want to insert before or after the word, without having to adjust your position! It's just a</code> or i</code>, depending on where you want to end up :D Even more powerfully, this behavior of a</code> and i</code> makes surrounding things really easy. First you press i</code> and type the left delimiter in, then a</code> to type in the right one. I remember there was a very hyperspecific feature in nvim-surround to let you do exactly this; here it's just part of the editing model, which is fascinating! However, I half-think that this a</code>/i</code> behavior is more of a side effect than intended behavior — your selection is updated when typing in with a</code>, but isn't with i</code>. So far that hasn't given me problems, but it does feel like a bug. Maybe will get fixed someday! I'll admit, all this selection business takes a while to get used to, but actually now I prefer it. Even in my fish shell "helix mode", I re-made this behavior, that's how much I like it! </hr> </a> Another example is p</code> and P</code>. Yep, they also paste after and before the selection. With them though, the behavior isn't particularly mind-boggling, and just ends up feeling correct immediately. Say you have word</code> selected, with your cursor on █ord</code>. After you yank, to multiply word</code>, you just press pp</code> as many times as you need. If you tried doing that in vim (same cursor position, after you yank with yiw</code>), you'd end up with wwordwordord</code>. I massively prefer just pressing p</code> mindlessly, rather than having to first move to the end of the word, or press Pppp</code> instead. And if I wanted to multiply backwards in vim, word</code> vores itself in an even more horrifying way: worworwordddword</code>. aha! the perfect editor!</a></h1> After all this glazing you might rightfully think "helix must be perfect!". Is that the case? FUCK NO! The big downside of helix is its lack of maturity and slowness of development. First of all, it doesn't have a plugin system. Yep, not at all! Even something like kakoune, which design is against the idea of plugins, does have a plugin system. Your shell has a plugin system. That itty bitty program that you click clack commands in. Your fridge probably has a plugin system. Helix doesn't! And because of this, you're bound to encounter problems that are currently unsolvable, as generally a plugin for that behavior would already exist, or you'd write your own to get it. This state of affairs makes it infuriating to use helix sometimes, because the :trim</code> command has been bikeshed for over a year, and some seemingly basic lsp methods are not implemented, leading to some lsps literally not working! The example I'm immediately thinking of, is the Scala lsp not working because it can't show its startup message. This may be niche, but papercuts do pile up! Have I already mentioned that you can't complete words from the document in helix stable</del> master? Yeah... This feature is completely working and finished, but is floating around as a PR for seemingly no reason at all. As I like to say: “if we consider all the unmerged completely finished and working PRs, we have a functioning editor!”. On one hand, we already have way more than enough features to have a really fucking good editor. Because it's designed so well, you tend to be able to work around the missing parts not too difficultly. But still, the more I learn about helix and its decisions, the more I think it holds itself back just to reach unecessary perfection; never trading "perfect" for "done". And basic editor features are so important, that I'd rather see them get merged asap, and then evolve over time into becoming perfect. But maybe that's unrealistic? is this a worthy tradeoff?</a></h2> But consider all the elegance of the editor I've discussed so far — was the slowness of development a necessary evil to achieve it? Is it the reason I even switched to helix in the first place? It's a difficult spot to be in emotionally, as I really do care deeply about this editor now 🥺. Regardless, the issues that come from not having a plugin system is why many people, including me, decide to make a personal helix fork</a>. Editing the source code of a text editor to get the missing features sounds, truthfully, insane. And like a lot of effort. That's what I thought, at least! Turns out, the developmental slowness has made the helix codebase really good. I don't think I'm that good at rust, however I keep getting surprised at how easy it is to add new features in. Especially coming from a lot of neovim configuration, I expect to go on a whole adventure to try to make something work, and then get surprised when my endeavor cost me 5 minutes at most. a happy dev adventure</a></h1> One feature I have in my fork (all features are listed in the readme) is that you can remove the statusline. Vaguely remembering how the statusline works in nvim, if you were to remove it, it would be unreasonable to think to enable it back on at runtime, without reloading neovim as a whole. I kept this assumption with helix — I put in only slight effort, just to be able to disable the statusline using a config option, not caring enough to implement the ability to switch it back on dynamically. After finishing the feature, I wanted to see how much things break if I try to :toggle should-statusline</code>. Imagine my surprise when nothing broke 🤯 Matter of fact, the statusline showed up with all the information up-to-date, no less! This flabbergastment of mine never stops: with every new feature I try to add, it generally goes far better than I expect. Traumatized by neovim configuration I guess! But it makes sense. Of course an editor that feels clean and consistent is also written in a clean and consistent way. This is all to say that if you decide against using my fork for whatever reason, consider forking it yourself anyway. You'll be pleased to see the features you want be easily addable, and considering how slow helix development moves, you won't need to rebase on upstream that often. Because of this ease though, you'll gain a habit of screaming "WHY ISN'T THIS IN CORE ALREADY", like I did :> helix master vs stable Axlefublr — Fri, 11 Oct 2024 00:00:00 +0000 When considering switching to helix master, I went through all the commits after stable. Here are the new features I discovered. pickers</a></h1> columns</a></h2> There's a picker refactor: most pickers now have columns, that you can search directly. Here's how the bindings picker looks like now: shorthands</a></h3> And thanks to columns, it's much nicer to use! You can type in %column_name</code> to start searching in that column. So you can search by specifically documentation by using %doc</code>: </hr> </a> Or just %d</code>! The column matcher just needs to be unique, from the start of the column name; you don't have to use the full name. </hr> </a> You can combine a normal search with a column search: And even multiple: global_search</a></h1> The global_search</code> action used to prompt you for the search in the commandline area, and then show the results at once. Now it is an interactive picker, and shows results as you type in the regex pattern: </hr> </a> Also has a column you can additionally filter by: inline diagnostics</a></h1> There's now an inline-diagnostics</code></a> option in the [editor]</code> section, that lets you have lsp-lines</a>-like diagnostics (without being super buggy, like that nvim plugin is). “snippets”</a></h1> Lsp snippets: when lsps complete extra text (default parameters for example), it now actually appears in the completed suggestion. It used to strangely dissapear. This snippet implementation is not full; you still can't go to the previous / next node in the snippet, for example. suggestions</a></h1> Extra information for suggestions now appears at the top / bottom of the screen, rather than being squished to the side of the suggestion box. So generally you get to look at it a bit more normally. macro mappings</a></h1> In mappings, you can now use @ to bind to literal keypresses. For example 'mw' = '@miw'</code>. camel case motion</a></h1> Subword movement actions. Search for them with sub_word</code> in the keybind picker. I went with using gw</code>, ge</code>, gb</code> (the first two are mapped by default, I moved those default mappings elsewhere). various fixes</del></a></h1> Hardlinks were broken: if you wrote to a hardlink, it wouldn't update the other file. This was fixed in master. why I hate kitty Axlefublr — Fri, 13 Sep 2024 00:00:00 +0000 I say "god I hate kitty" a lot, but I usually can't think of examples for why on the spot. I just encountered yet another "god I hate" about kitty, so I'm gonna write it down while it's hot to transfer why I hate this terminal emulator so much. </hr> </a> I wanted a certain feature: in the tab bar, usually I want tabs to just have their number displayed, and nothing else. But optionally, I should be able to add a title to an individual tab. You might reasonably think "oh that sure sounds like a job for a plugin" and in any other app, something this specific would require a plugin, yes. Kitty, however, picks to be between a rock and a hard place. </hr> </a> Usually when configuring things, ideas come to mind because I already have a very vague idea of how to do it / assume it's doable. It was the case here too: there's an option called tab_title_template</code> that lets you define the text displayed in each individual tab in the tab bar. Aside from feeling a bit wonky (have a look</a>), I actually quite like it because it's pretty flexible for a config-based terminal emulator (rather than one that uses a programming language directly, like wezterm). So I put in the title there and went on to configure. </hr> </a> A lot of terminal applications change the shell title (or window title you would usually call it?), so once I configured them to not, I was able to get to fish_title</code>. fish_title</code> is fish shell's mechanism for setting the shell title, and it's really cool! You can use arbitrary fish shell logic to print the exact title that you want. I used to use it a long time ago, but found the concept of changing shell title more distracting than useful, so I removed it. I came back to it now to try to make it more useful: usually the title would be some reasonable default I define in fish_title</code>, but I could also override it to be something else instead. I used an arbitrary variable called title</code> that I could set to do that overriding, all in my shell. That sounds like a finished job, doesn't it? But here comes in kitty, trying to be useful in the most annoying way. </hr> </a> fish_title</code> runs before and after making your shell prompt, and there can be times where fish doesn't report its title, or sets it to a blank string, before setting it again. In actual usage what ended up happening, is sometimes my kitty tab title changed to fish</code> for a flash, and then got back to the title defined in fish_title</code>. So I thought "huh, maybe fish is reporting some fish -c</code> action and so is setting the title to that?" — my logic for making the title was pretty solid, but I assumed it allowed something like that to happen. My solution for this was to stop trying to make the title useful, and disable it completely. I set fish_title</code> to be a blank function the echoes nothing. Imagine my horror when after doing so, I still see fish</code>. ??? wtf the title is supposed to be blank now? And now I realize that fish was doing its work perfectly fine, and there was no issue there to begin with — it was kitty's default messing things up. </hr> </a> So turns out (I don't think it's documented, at least I wasn't able to come across this in the documentation) in kitty, if your shell hasn't got the shell title set, it will default to whatever the current app running is. That fish</code> was kitty saying "hey! you're running fish!" because I was just looking at my shell. I have some kitty mappings that open programs directly in overlay windows (which are REALLY cool btw), and once I opened yazi</code> like that, I saw yazi</code> in the window title. Eureka! 🥳 You know what this means now? The fish shell titling mechanism is effectively useless, because kitty will interrupt and set a default intermittently with fish, so the tab title will jump jarringly and is therefore not worth using. </hr> </a> I set the shell_integration</code> kitty option to no-title</code>. While we disabled fish_title</code>, some programs can still set the shell title themselves, and that option ensures that it's ignored. Now only kitty has the capability to set its own tab titles. Now practically every tab has fish</code> in its title, that sometimes turns into yazi</code> / lazygit</code>. The latter is kinda cool, but having fish</code> in every title is pretty jarringly useless. The other piece of the puzzle, set_tab_title</code>, is a kitty action you can map to, that will let you interactively change the tab title. With it, I have a solution: I could rename every tab I use to make more sense, rather than being just fish</code>. But also, that's pretty unreasonable to ask of myself — I create and close tabs all the time, very quickly, and in reality I'll just end up seeing a lot of 🐟es in my tab titles, and sometimes see my actual titles. All that plus I'll feel more pressured to title tabs that I don't actually care to have titles. Between a rock and a hard place. </hr> </a> A VERY obvious solution that you might've just thought about is to just disable this default kitty functionality that sets the titles to begin with. Very reasonable! I thought about it too, but you can't disable it, as far as I'm aware 💀 You might now think "well surely that's a bug! you should open an issue about this" which is once again reasonable, but I already got burned on that with kitty. </hr> </a> Kitty is infamous, first and foremost, for its unbearable dev. He instantly closes issues (which in itself is not an issue (lol)), rudely disregarding often times reasonable concerns. My story: You can set the shape of the cursor in kitty with the cursor_shape</code> option. It can be one of block</code>, beam</code>, underline</code>. There is also a cursor_shape_unfocused</code> option. Does the same thing, but for when kitty is not in focus. Except, it can also be hollow</code>. Yes, you cannot set cursor_shape</code> to hollow</code>, but can set it for cursor_shape_unfocused</code>! That seemed like an obvious misstep but I've been taught by others that sometimes even "obvious" things should be reported in issues and worked on in PRs, so I created a PR adding hollow</code> to cursor_shape</code>. ...Instantly rejected with something along the lines of "this is stupid, the hollow</code> shape shows that kitty is unfocused". This is awful on multiple levels. </hr> </a> Sure, cursor_shape</code> being hollow</code> by default would be stupid, but there should be an option to set it, because it's up to the USER to decide that for themselves. You never fully know the usecase of each user, and should allow them to be "stupid" if that's what they actually want. The argument also doesn't hold up because you can set set both cursor_shape</code> and cursor_shape_unfocused</code> to block and continue to "not know if kitty is focused or not", so why should you be unable to set them both to hollow</code>?? If your window manager and kitty window borders already make things clear, it's not unreasonable to not care about the cursor shape, especially considering that the hollow cursor looks really cool! I would 30% understand if I opened an issue, but I opened a PR that just adds that, so all you have to do is press accept and blammo! The change is literally two lines, one of which is the docs, so even the maintenance argument doesn't hold weight here. This same exact feature request I opened as an issue in ghostty, the dev said "huh I don't see why not" and implemented it a couple of days later. Night and day. If this was my only interaction with the kitty dev, I would give him the benefit of the doubt (although would still be annoyed), but all I hear about the kitty dev from people is mostly stories like mine. </hr> </a> Coming back to shell titles: this is why it's not worth the effort to open an issue to make the default kitty titling behavior disableable. I could potentially change it in source code and compile my own kitty, but I have no clue how to compile kitty — it feels like a big mishmash of everything that I really wouldn't want to work with, even though I do keep a helix fork</a>. </hr> </a> Next I came across session files</a>. "Surely the bee's knees" I thought — they allow you to specify a bunch of kitty commands to execute on startup. Buuuut on startup of the instance, so they won't control each individual window / tab, which is what I would need. Even calling set_tab_title</code> in the session file didn't do anything for even the first window (which I don't exactly get). </hr> </a> The final possibility is "watchers". Python scripts that listen on kitty events and execute kitty code on them. That's what I'm guessing they are anyway, because I dismissed them instantly out of this thought process: Oppositely from session files, the watcher would run on... when exactly? Let's say I'm lucky and there's a "title changed" event. Will that event run on startup? This is only based on my overall experience using kitty, but I assumed it would for some reason not, specialcasing when you first launch kitty, and working normally all the following windows. I have no reason to think this except kitty being similarly horrible to me like 20 other times, so this isn't really a "point". For all I know, watchers might be the bee's knees but at this point I was tired and making a python script to work around yet another "nice" kitty behavior didn't seem worth it. </hr> </a> So I give up. I get hyperfocused on things like this often and that can put me in a spiral. I went and did some house chores, until I got another idea... In tab_title_template</code>, this is offhandedly mentioned: Note that formatting is done by Python’s string formatting machinery </blockquote> I mostly diregarded this because what in the living and dying hell is "string formatting machinery". The limits of how it actually works are not well defined in the docs, so that's why I went on to try other options that felt viable, before coming to this one. </hr> </a> In the docs, we get this example: {layout_name[:2].upper()}</code> I realize that I can at least slice strings and call methods on them. This by itself is not strong enough for what I'm trying to do, so I decided to take a gamble: what if "string formatting machinery" is actually "python expression"? To reiterate the behavior that I want: usually the tab titles are 1</code>, where 1 is the amount of windows on that tab. I should also use my mapping for set_tab_title</code> to append some text to it like 1 asdf</code>. So I need to somehow filter all titles that kitty might automatically set (i.e. any possible name for a program). I also need to handle the space after the number and before the title, and the rightmost space, to keep to correct padding. </hr> </a> Behold: yet another kitty wack solution that does what I want, through a hack: " {fmt.fg.pink}{bell_symbol}{activity_symbol}{fmt.fg.tab}{num_windows}{title[0] == ' ' and title or ''} "</code></pre> or, simplified, " {num_windows}{title[0] == ' ' and title or ''} "</code></pre> It turned out that "python string formatting machinery" does just mean "python expression". Amazing docs as always kitty, very clear /s Using a python expression, I can use a ternary (the and or</code> there) to filter out titles set by kitty. I'm hoping and coping that no title set by kitty will start with a space (I would still be only slightly surprised, though, it's kitty after all), and because I need a space between the number and the title, if I always start my tab titles with a space, I get to solve two issues in one approach! Press my set_tab_title</code> hotkey</li> Type in gist</code> (with a space before)</li> Bob becomes the brother of your parent</li> </ol> </hr> </a> So while I have my desired behavior, I'm obviously unhappy about it. It's a hack as clear as day. The real issue with kitty that makes me so mad at it, is that it shines gold coins at you all over the place, suggesting that making some feature you assume is obvious is going to be easy. It shows you multiple different approaches through its functionality, and so you think "with so many options, surely this is trivial". And yet, time and time again, I come across poorly worded / explained documentation, strange "useful" default behavior I have to work around, a very unhelpful dev that I can simply ignore trying to contact for better behavior, a messy project structure where it's not viable (at least for me) to keep a personal fork, a billion features, all of which are somehow just not enough for the functionality I want, but enough to make me excited to try implementing it, and an autistic brain that makes me want to configure my tools in ways that apparently no one else has wanted. Somehow. Sounds awful, doesn't it? If you were as into configuring your terminal, I'm sure you would hate kitty too. conclusion</a></h1> All of these are reasons for why I use kitty but can't recommend it. I can easily recommend alacritty, though. Alacritty can't do shit but doesn't claim it can, so you have to just deal with it. Helix can't do shit and doesn't claim you can, so you have to just deal with it (you can draw the same connection between neovim and helix as I am drawing with kitty and alacritty). I hope that draws a clear enough picture for my hatred towards this feline terminal emulator 🐈. I gave two examples here but you should subconsciously multiply them by at least 7. This is not my first or last kitty configuring adventure that goes in me hating it more, this is just the first time I caught it and decided to write it down. why kitty then?</a></h2> The worst part about all of this is that I now have yet another cool and useful feature that is either hard or impossible to recreate in another terminal emulator, so I'm bound to use a terminal I despise. Kitty has better looking and faster rendering than anything else (except maybe ghostty, although ime ghostty was slower, and I was trying to like ghostty so I doubt it was bias). It slightly boldens fonts which is REALLY weird for it to do but now I really love it and can't live without. It doesn't make ANY gui-like elements, which I hate especially in terminals: even the tab bar looks like it's from a tui application. The remote window manipulation is super powerful, and I make a lot of use from windows, tabs, layouts, overlays (omg the overlays 😩) (yet another painful config adventure). Kitty can work as a "server" for kitty, letting you create new os windows practically instantly (ghostty can do this too but in a different way and slower) (this adventure was especially painful). The binding system is really powerful and lets me use chord mappings. The supposed "new best terminal" ghostty has some of these features, but they often times are not as good, or just equal; some things are missing or work worse so I don't feel encouraged to switch off kitty, and I am... between a rock and a hard place </blockquote> a neat helix multicursor trick Axlefublr — Sun, 01 Sep 2024 00:00:00 +0000 You may sometimes want to set a bunch of multicursors on a lot of lines, where just holding C</code> and letting key repeat do the job is a bit bothersome. So you mip</code> to select inside paragraph, and use s</code> to set cursors how you usually would with C</code>, but with far less keystrokes </video> Doing this feels illegal fwiw, but it's actually super valid for this usecase, where you want to act on a certain column, rather than anything that you can regex match by text. If you know exactly how many columns you need to match, you could also just ^.{30}</code> or something, but I generally don't know. Regex is really powerful in theory, really fun to learn how to use it more creatively. why I hate lua Axlefublr — Fri, 05 Jul 2024 00:00:00 +0000 What I value most in a language is functionality — what and how easily the language lets me do things. No wonder! That's what programming is kinda for: doing cool things more easily. And here's lua, that doesn't even have an abstraction over something as simple as .split()</code>. Ridiculous. </hr> </a> Lua has a very weak standard library. You'll find yourself reimplementing functionality that you'll be flabbergasted isn't there to begin with. Sure, some of that functionality might be simple to implement, but it shouldn't be my job. Imagine doing the equivalent of implementing the print</code> function in every new project you create. It's disheartening. Not only is the standard library weak, but it's also not ergonomic. Whenever you want to push a value into an array (more precisely a list / vector), the way that you're used to doing so in basically every language on earth is this: my_array.push(value)</code>. Well duh! Right? Right... </hr> </a> The way you do that in lua is table.insert(my_table, value)</code>. "Oh it sure looks like the expanded version of the method syntax, so you can just do my_table:insert(value)</code> and it'll work surely" — yeah that's what I wished too. What is sometimes an implementation detail in some languages, is actually the way you're supposed to call, what should be by all accounts, a method. Insert is not a method for any table, which is the obvious thing that you want, no. It's a function that just happens to be in the table</code> module. This kind of idea repeats with stuff like math.abs()</code>, but math being stored in the balls</del> a module is a pretty common thing across languages, and not too insulting. An action you're doing on an object being a function is very insulting. </hr> </a> You know how you can fix this though? With inscrutable symbol soup! local my_table = setmetatable({}, { __index = table })</code></pre> And now you can do: my_table:insert(value)</code></pre> Yipee 🥳 right? Yeah fuck no! Why is this bullshit not the default? It is not reasonable at all to insert that symbol soup every time you want to make a table, just to get slightly better syntax. The confusion you'll get from (most) people is simply not worth it. So I'm stuck between a rock and a hard place. You could I guess make this: local function get_reasonable_table() return setmetatable({}, { __index = table }) end</code></pre> But even with this, this is a bit stupid. Remember, we're not doing this to inherit some table in our designed app, we're doing this just to have slightly better syntax. So I once again argue that it's not worth it. </hr> </a> Notice how both that variable and function use the local</code> keyword? Yeah that's because both of those would otherwise be global by default. Because that's a very good idea for a default /s To reiterate: why in living and dying hell are those not local by default? And then you'd maybe opt into globality via global</code>?? Autohotkey does it and it's great there! A bunch of other languages make globality more annoying to use, which is overall a good idea hehehe :3 Or perhaps they use the concept of const</code>, which covers a lot of the cases for wanting globality anyway. Additionally confusingly, you need the local</code> keyword even if you're not in a block / function. Because without it, the variable won't just be global in the file you're working on, nope — it's going to be global to everywhere. So you put the local</code> keyword to make the variable "local to the module". This language is a god's mistake. </hr> </a> But we continue on: if a feature exists, makes sense to use it. Even goto</code>s have their use, I'm sure. (While writing I mentioned goto</code>s as a joke, only to then realize they actually exist in lua... Yes, goto</code>s, but not the FUCKING CONTINUE STATEMENT. Yes, really. I'm way ahead of you and I have been crying about it, don't worry.) The convention for variables and functions in lua seems to be using snake_case</code>. Alrightie then. Another convention, suggested by the lua language server, is to make at least the first letter of global variables uppercase. What I think is suggests is SCREAMING_SNAKE_CASE</code>. This of course makes a lot of sense for global variables that are meant to be const</code>s. ("pinky promise const</code>s", because the concept of actual const</code> in lua doesn't exist, and all variables are mutable) But not all global variables are meant to be const</code>s, many of them will be global just so that they can be accessed from anywhere conveniently. So we can't just lie and use that upper case, because it will confuse programmers looking at our code, when we modify (after instantiation) what looks like an immutable variable. What other choice do we have? PascalCase</code>? No!! That's obscene. The convention is still "variables use underscores to separate subwords", so why would we suddenly change that because of globality? It makes no sense. And, I can understand a pascal case function, cause that does appear in some languages (like C#). A pascal case variable is really out of the blue, considering it's not the usual case in lua, or any other language I've worked with. So what am I left with? This_stupid_bullshit</code>. To satisfy both conventions, I have to do something as ridiculous as that. I will shoot anyone that argues for this absolute strawman of a casing convention. If we bring it back to using SCREAMING_SNAKE_CASE</code> disregarding the const</code>-related confusion, then we'd have to name functions in that case too. Which is a whole another level of cursed. local thingy = YEP_JUST_A_GLOBAL_FUNCTION(params)</code></pre> What the fuck. </hr> </a> You might say "well you could just ignore the suggestion by the language server" — I wholeheartedly reject that notion. The lua language server will be used by the overwhelming majority of people that program in lua. The majority sets a standard, and a good programmer follows standards (yes, even if they're stupid!). So I can't just ignore it. I haven't looked at much lua code aside from that I wrote (cause remember, I fucking despise the language!), but it seems like the convention is to just never use global variables lol. Which is, like, fair. </hr> </a> Lua uses the concept of "first level citizen functions". Or however that concept is properly worded. Basically, functions are just values that you can assign to variables, and store in tables. That kind of behavior is actually pretty cool, and makes sense for the language. The problem I have with them is the syntax. Think of basically any language that uses the concept of closures. Rust's |x|</code> (stupid but consise), python's lambda</code>, javascript's (x) => {}</code>. All three differentiate functions and closures, fwiw, so they might not be good examples, but my point is that you can make syntax for closures that is nice and consise. If you wanted to interpret functions and closures in the same way, using fn</code> / def</code> / fun</code> / etc works just as well. Then why in living and dying hell does it have to be function</code>. Bitch, you might as well write an entire poem just to define an anonymous closure in lua by that point. God am I mad at this in specific. Because of how neat the concept of "functions are also closures" is in lua, it's very very commonly used. And any time you need to pass some closure as an argument, you have to boilerplate it with typing out function</code>. Just fun</code>, def</code>, fn</code>, func</code> would all work! I'm sure you might have a distaste for some of them, but you'll probably see at least one to be "alright as a closure starter". So yeah, it genuinely doesn't need to be that long. </hr> </a> "Oh, lua is made to be readable and approachable to newbie programmers!" </blockquote> That's a good benefit! There are for sure some things that make sense to change to make them more approachable to newbies. An example of that could be {}</code> vs indentation in python. I have genuinely heard {}</code> confusing people, and making it harder for people to read code. This is not the case for me anymore, but I do remember the time when I was just starting out, where that definitely was the case. {}</code> were harder to visually parse. You cannot make this same argument for function</code> vs func</code>. The latter is just as visible as the former, and just as obvious literally as soon as you define your first function in lua. Your second function forward, you now have to deal with typing out the entirety of function</code>. </hr> </a> "Oh just autocomplete it" </blockquote> Yeah no. Most (lua) programmers are on vscode, and that editor will generally not be fast enough to make it worth it to complete function</code>. By the time the suggestion window appears and you pick the correct thing (cause also remember, most people don't realize they can fuzzy search their suggestions), you would have already typed in function</code>. So the result is you always just typing in function</code> yourself. func</code> would reduce that by half, and would be quite ergonomic. </hr> </a> Actually, forget that "approachable to newbies" point, cause it's obscene in its own sense. Let's talk about lua patterns. Do you know how they work? I sure don't. Instead of implementing regex, lua has its own flavor of pattern matching with its gsub</code>s and the like. In those, you have to use lua patterns. They sometimes resemble regex, but for some odd reason don't try to fully emulate it. And let me also mention that you can't just my_str:contains(literal_string)</code> — you'd have to use gmatch</code> I believe, and that has to use lua patterns, meaning you can't just conveniently raw compare a substring. What a travesty. The main point behind not implementing regex is that it would double the size of the lua binary. I personally couldn't give two shits, but I can see it as an important concern, so I don't have much against that point. So, what I'd expect is for lua to match the syntax of regex, but just have a bunch of missing features. If that was the case, there wouldn't be a "patterns" section in this rant. But no, lua decides to use its own syntax, that you now have to learn, even if you're familiar with regex. Why do I then not complain about rust not having regex? That's because it has enough features to make it very viable to not use it — you have other ways of achieving the same text parsing objective. And you have the obvious .contains()</code>. </hr> </a> Coming back to syntax: why does then</code> need to exist? It's used in if</code> statements for example. Statements that only take a single expression as a condition anyway. So it's already as clear as day where that condition ends! Because it's required to end after a single expression! And so, everything else should be considered the body of the if</code> statement, and there's no confusion. And yet we stil have then</code> for some odd reason. Fish shell very comfortably doesn't! I don't like the end</code>-type "bracket keywords" in programming languages, but I can see how it's needed in something like fish shell. It does not need to be so in a "proper programming language" which I expected lua to be. </hr> </a> Worst thing about lua is the fact that every goddamn configurable thingy in existence seems to immediately go for this piece of shit language, resulting in both my window manager and text editor to be configured in it. Lua is unfortunately my most used programming language, however mad I am at this fact being the truth. Other languages that I've seen people dislike are lisp and haskell. I haven't tried either of them, maybe I would like them maybe not, but regardless, I retain my possibility of avoiding them if I so desire. Lua is fucking inescapable. "Oh you might like Fennel then!" </blockquote> (yes every possible argument made towards me by the reader will start with "Oh") Good suggestion! I honestly might. But having to use a language to fix another is just another proof of lua being a shit language. Kinda like the javascript vs typescript situation. What I use lua for is configuration. If I want functionality, I'll pick fish shell any day over lua. So creating a level of abstraction over my configuration-based lua is just an extra complexity that I'll have to deal with. Making it not worth it conceptually. This is the reason why I haven't rewritten my neovim config in rust (which you can supposedly do, as it turns out). P.S.</a></h1> Everything I've learnt about lua was against my will, so if I'm wrong on some points in this rant, don't be surprised. I'm not interested in giving a language I hate more time than I already do, to learn how to circumvent its annoyances. This rant is also against lua, not against lua likers. I believe it's (almost) always better to like something than to not, so if you enjoy the language, you're better off than me!