This has bugged me since I got a ThinkPad X270, so much so that I actually found/made time for Frustration Driven Development, figured out a patch for the source code, built the kernel and tested it out. This has MASSIVELY IMPROVED my laptop experience. Honestly, not overstating that. Due to the Synaptics driver doing tap-to-click by default I would frequently make mis-clicks with my palm, etc when typing and would often mis-click and accidentally drag tabs, etc in Firefox. I was coming very close to disabling the trackpad altogether and using the pointer instead, but then “solved” half the problem by disabling mouse mode in Helix - although it was still annoying me elsewhere.

I patched it so tap to click is the default behaviour and I can just easily disable via sudo sysctl -w hw.synaptics.tap_to_click=0:

--- /usr/src/sys/dev/pckbport/synaptics.c.orig	2024-06-22 11:02:05.000000000 +0100
+++ /usr/src/sys/dev/pckbport/synaptics.c	2026-04-22 17:21:33.087414774 +0100
@@ -118,6 +118,7 @@
 static int synaptics_button_boundary = SYNAPTICS_EDGE_BOTTOM;
 static int synaptics_button2;
 static int synaptics_button3;
+static int synaptics_tap_to_click = 1;
 static int synaptics_two_fingers_emul = 0;
 static int synaptics_scale_x = 8;
 static int synaptics_scale_y = 8;
@@ -155,6 +156,7 @@
 static int synaptics_edge_motion_delta_nodenum;
 static int synaptics_finger_high_nodenum;
 static int synaptics_finger_low_nodenum;
+static int synaptics_tap_to_click_nodenum;
 static int synaptics_two_fingers_emul_nodenum;
 static int synaptics_scale_x_nodenum;
 static int synaptics_scale_y_nodenum;
@@ -865,6 +867,18 @@
 
 	if ((rc = sysctl_createv(clog, 0, NULL, &node,
 	    CTLFLAG_PERMANENT | CTLFLAG_READWRITE,
+	    CTLTYPE_INT, "tap_to_click",
+	    SYSCTL_DESCR("Enable tap to click"),
+	    pms_sysctl_synaptics_verify, 0,
+	    &synaptics_tap_to_click,
+	    0, CTL_HW, root_num, CTL_CREATE,
+	    CTL_EOL)) != 0)
+		goto err;
+
+	synaptics_tap_to_click_nodenum = node->sysctl_num;
+
+	if ((rc = sysctl_createv(clog, 0, NULL, &node,
+	    CTLFLAG_PERMANENT | CTLFLAG_READWRITE,
 	    CTLTYPE_INT, "two_fingers_emulation",
 	    SYSCTL_DESCR("Map two fingers to middle button"),
 	    pms_sysctl_synaptics_verify, 0,
@@ -1101,6 +1115,10 @@
 		if (t < 0 || t > 3)
 			return (EINVAL);
 	} else
+	if (node.sysctl_num == synaptics_tap_to_click_nodenum) {
+		if (t < 0 || t > 1)
+			return (EINVAL);
+	} else
 	if (node.sysctl_num == synaptics_two_fingers_emul_nodenum) {
 		if (t < 0 || t > 2)
 			return (EINVAL);
@@ -2293,7 +2311,7 @@
 	/*
 	 * Do gesture processing only if we didn't detect a palm.
 	 */
-	if (palm == 0)
+	if (palm == 0 && synaptics_tap_to_click)
 		synaptics_gesture_detect(sc, sp, fingers);
 	else
 		sc->gesture_type = sc->gesture_buttons = 0;

I haven’t noticed any downsides to this at all yet. I have physical buttons that I can use for clicking anyway PLUS it turns out if I press hard enough (I’d never done this because of tap-to-click) on the trackpad it actually physically clicks (and that still registers as a click with this patch).

I must be some kind of freak for hating tap to click (I hate it on macOS as well) since no one has bothered to change this over the years. Or even moaned that much about it.

I couldn’t recall trackpad usage on my previous NetBSD laptop being this bad, but then I looked up that hardware and realised it didn’t have a trackpad.

[EDIT: 2026-05-04] It got committed. Whoop!

• Tags:
  • program

Since using lots of Vim sessions in a terminal I had a brief dalliance with Nova (I did/do like it, but it’s not cross-platform) and then ended up with Helix. At work I tend to use Helix in the same way I was using Vim but instead of Terminal.app it’s Alacritty with one huuuuge Tmux session with multiple windows (“tabs”) per each Git repository I’m working on. I haven’t bothered figuring out renaming the tmux windows automatically and just rename them manually - it tends to be a very long running Tmux session that I also save and restore so renaming manually is a one-time thing. It is easy to find whichever repo I want (across 70+ windows) by using CTRL, b, w to bring up Tmux’s window search and then using / to search for the name I want.

Since starting to play about with AI clis, I’ll split the Tmux window so I have a pane for running the cli in and a pane for Helix. But I won’t be running an AI cli in all of these windows which has lead me to wonder, “How do I find where I’m running AI clis?”.

What I’ve done is add a simple wrapper to the AI cli command to set and unset Tmux window titles on launch and quit of the AI cli:

function ai {
	# Let me know where I'm running an AI cli session
	
	# Find tmux window this command was called from
	# This way can target window. 
	# And avoid racey style stuff where wrong "current window" gets renamed
	twin=$(tmux list-panes -a | grep "$TMUX_PANE " | cut -d : -f 2 | cut -d . -f 1)
	twse=$(tmux list-panes -a | grep "$TMUX_PANE " | cut -d : -f 1)
	# I don't think I'd ever use an asterisk as a window name, but this would fallover if I did
	twnm=$(tmux list-windows -a | grep "$twse:$twin:" | cut -d : -f 3 | cut -d ' ' -f 2 | cut -d '*' -f 1)
	tmux rename-window -t $twin "$twnm + ai"
	/path/to/ai/cli
	tmux rename-window -t $twin $twnm
}

And now I can easily search through my Tmux windows.

• Tags:
  • program

NetBSD themselves have a no AI policy (fair; at some point lawyers are going to make a mint), but I just wanted to have a play about and since I run NetBSD, perhaps for too long, I just assumed I was out of luck with most AI tooling (most things do just target macOS, Windows and Linux). But it turns out things are mostly ok thanks to all the CLI tooling being node/npm:

• Gemini just works* (and requires nothing more than a Google account; Which I have again since switching to Android)
• Codex throws an unsupported platform (I wonder if this could be worked around?)
• Claude runs (but there is no free tier)
• Qwen code works (requires a free account; Looks like a Gemini clone)

(Don’t use global installs)

I started with Gemini - I thought I’d jump in the deep end and ask it to do something useful and something fairly complex so I asked it to build me a Chrome Cast receiver in python - I’d love to be able to cast from my Pixel to my NetBSD laptop. It “worked” in that it built something that looked sensible and did run although didn’t actually work when it came to being a Chrome Cast receiver. So then I thought I’d step back a bit and ask it to migrate simplenote.py (long neglected by me) from Travis to Github Actions; Because this is the kind of thing I’ve been meaning to do for a few years and just haven’t found the time for; I.e. this seems like the kind of “chore” task we should be using AI for instead of all the terrible things we are using AI for.

Comparing Gemini with Qwen

For both I gave a prompt like this (apart from the branch name being different):

Create a branch of this repository called gemini-github-actions and migrate the Travis CI setup to Github Actions

And then also gave both permissions for whatever it asked for for the session.

Both gave me additional instructions. Gemini:

To verify the migration, you should push this branch and ensure the GitHub Actions runner can successfully execute the tests and build the package. If you want to proceed with a commit, please let me know.

Qwen:

Next steps:

1. Add PyPI credentials to GitHub repository secrets (PYPI_USERNAME and PYPI_PASSWORD)
2. The deploy job triggers on release publication (modern approach vs. Travis’s tag-based deployment)

Personally I find it dumb that neither of them committed automatically (why would I be telling you to create a branch?) so I told both:

Please commit your changes including the summary of the changes you’ve just provided in the commit message.

Qwen had just created the .github/workflows/ci.yml file whereas Gemini also removed the .travis.yml and updated the README badges (nice); However, I LOVE that Qwen co-authored the commit by default.

I told Qwen:

Please also delete the .travis.yml and update the README badges to suit Github Actions ​

to get it in the same state.

(Interesting aside… I had to update my PAT to allow creation and updates of workflows before I could push)

Here’s the final results (final at the time of publishing is one commit on the gemini branch and two on the qwen one):

1. Gemini
2. Qwen

There are some subtle differences. Gemini includes many more python versions, Qwen just two, matching exactly what I had for Travis.

Of these two, only the Gemini branch automatically triggered a Github Actions run because it sensibly included its own branch - it failed though on every single job. Don’t actually know why. Github just tells me all the jobs exceeded the maximum execution times whilst waiting for runners.

In an effort to actually publish this post this year I am going to leave the AI efforts there for now - I might continue with both branches and get Gemini and Qwen to make further tweaks or I might continue by hand, but that could take me days, or weeks. Or months. So this will do for now. There’s no conclusions to this post, just observations - literally just me documenting my playing about.

This post has taken me months to write. I’m just too busy. I’ve been wanting to play with AI CLI tooling because up until just the last day or so I’ve not been allowed to use any such tooling at work (believe it or not). At least my tinkering on NetBSD did give me a little bit of a headstart and familiarisation.

* - Worked until this change since that it now gives env: unknown option -- S on NetBSD. Reverting that makes it work again. For me that was these files:

• /home/me/node_modules/.bin/gemini
• /home/me/node_modules/@google/gemini-cli/dist/index.d.ts

• Tags:
  • program