Tooling

Following a recent realization that jargons are fun, experimenting with prompts that inform LLMs to talk in outlines and jargons, assuming the reader is competent. Producitvity is up.

.dotfiles commit for linked context : https://github.com/rajp152k/.dotfiles/commit/28dd1385cc4370dd0b15774bb96a661b3cab628f

You respond exclusively in highly concise, jargon-rich org-mode only outlines, without any bold or italics formatting: the reader is a competent expert with polymathic knowledge and exceptional contextual comprehension. Do not provide explanations unless asked for further simplifications; instead, communicate with precision and expect the reader to grasp complex concepts and implicit connections immediately. Do not use any filler sentences and collabaratively contribute in constructing whatever topic is being expanded upon

Nth Roam : An Emacs package to efficiently manage multiple roam instances

I’ve always maintained a philosophical appetite for the tooling that I use.

One of the core tenets of the Unix Philosophy¹ is that everything is a file…

Plan9² has caught my eye due to its more homogenous design than the usual unix you’re used to.

The footnoted-paper (~pre-mature book) is somewhat unhinged and doesn’t shy away from taking a jab at the Unix ecosystem and design.

Apart from the several points the author makes, what stands out the most for me is the idea of everything truly being a file: in hindsight, Unix only realizes a fraction of the principle.

I’ve started spending some time per day without the usual modern software engineering tooling (LLMs, the Internet, etc) to explicitly maintain my cyber-deduction skills (in the context of Unix-based systems (BSDs, Linux, yet to explore Plan9), mostly because they power the majority of the global compute infrastructure).

It’s fun: init your journey with a man man (I’m an info info guy myself) and be extremely skeptical of your usual modus operandi, ditching all assumptions and tumbling down the rabbit hole.

Fabric¹ is a collection of crowd-sourced prompts, exposed via a CLI tool. I used it for a while some time ago but never fully exploited it because I prefer Emacs.

Eshell buffers are an option, but I am principled in my tool usage and prefer to delegate longer-running CLI tasks to a combination of Alacritty and Tmux.

Maintaining my Emacs shell usage to ephemeral popups feels natural.

Gptel² is a versatile LLM client that integrates smoothly into my workflow (buffer/text manipulation and management) without disrupting my thought flow.

I’m using monitors again and it’s like consuming caffeine after a long time (last recorded usage circa mid November 2024).

I guess I need to cycle my dosage so that I don’t end up being too dependent.

I’m enjoying it though.

EDIT: as of <2025-01-27 17:50:30 IST>, I’ve given up again

A while ago, I had the strong desire to partition some of my professional work logs into mutually exclusive git repositories: with Blacklists and Whitelists flipped.

I was aware that the .gitignore could ignore stuff; today I found out that I can also whitelist stuff via that.

checkout ¹ this stackoverflow question

So if the first .gitignore looks like

asdf-pattern 
more-asdf
some-absolute-asdf
dir-asdf/

the second one would look like:

# blacklist everything first
*

# unignore the directories to capture nested existences
!*/

# then your usual unignores
!asdf-pattern
!more-asdf
!some-absoluete-asdf
!dir-asdf/

What I wonder now is if git would allow for a branch-contextual .gitignore (named with certain protocols) so that I don’t have to maintain two different repositories altogether.

I recently have moved on from using monitors and am working (professional and writing endeavours) only via a 13 inch laptop. It is definitely a different workflow than what I’m used to.

It has been around 10 days I’ve been doing this and here are some observations:

• I’m able to focus better as I’m forced to enlarge my context maintaining capabilities; for I don’t have the luxury to look back and forth with just my eye movements.
• I can work from anywhere. I change places and posture every 1.5 hours, 5 times a day.
• Given I move between a couple of meets during the day, I don’t have to adjust to differing window management mannerisms as I only ever work on the same screen now.
• I work in at most two splits now compared to the 5+ previously: it is all simpler and the monitor has started to seem like a vanity rather than essential accessory.
• I don’t have to switch keyboards between my desk and meets: I don’t mess enough as much now.
• I can start looking down upon people that are bound to monitors, thinking that they’re spoiled or aren’t minimal enough.
• I’ve started preaching about the spartan-ish effects of working only via your laptop
• I spend more time on screen, on my bed: consequently I’m writing more.

I definitely do miss reading papers and books on a larger vertically oriented screen but I’m going to stick to this for a while.

There’s this saying :

If you’re stuck on an island and have the opportunity to build all of the software landscape again, the programming language you should choose is C. But the first thing you should write is a lisp interpreter.

I’m going to do that with Go.

As for the saying, I’ve heavily paraphrased (aka butchered) that and don’t quite recall the source so do excuse me for that.

This is how I time my workblocks these days…

Prerequisites

• ALSA : https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture

Functions

single_beep() {
( \speaker-test --frequency $1 --test sine )&
pid=$!
\sleep  0.${2}s
\kill -9 $pid
}

morse(){
for i in {1..3};
do
        single_beep 400 $1
        \sleep 0.${2}s
done
}

sos() {
    morse 200 500
    morse 400 500
    morse 200 500
}

timer() {
    \sleep $1 && sos &
}

Usage

The above can be sourced in your shell rc.
I store it in a .bash_funcs where I have all my functions and source them in the end of my rc as source ~/.bash_funcs.