plan9port VS plan9port

Acme has a handful of keybindings, like the usual ^A, ^E for navigation, ^Z for undo, etc. Plugging in new ones is a few lines of code, for example my ^S for Putall (saving all windows):

https://github.com/dexen/plan9port/commit/78324a4666c4b5e0bd...

Most of keybindings you might want to add are handled by Acme's "commands" - like Edit. If you repeat them any often, it's easy and straightforward to connect the keybinding to the command in code. Alternatively, to avoid going into C, write a shell script with ready-made command; Acme is well prepared to be managed through shell scripts. The shell scripts have full access to Acme's Windows (open files, directories, scratchpads etc), including ability to edit content, open new ones, interpret right-clicks in new ways, etc.

Acme is genuinely worth trying, you can run it on Linux/Mac without a VM [1]. I'm pretty sure Russ Cox [2] and Rob Pike use it as their daily driver which is insane because it doesn't even have syntax highlighting. I used it for years when I was in school as an exercise in masochism, but I learned a lot about Unix, and the mouse-driven workflow actually grew on me.

[1]: https://9fans.github.io/plan9port/

[2] https://9fans.github.io/plan9port/

If you find it too complicated and closely tied to Go internals, you can also check out Plan 9 from User Space's version, which is itself based on libthread from Plan 9 starting from 3rd edition, which is itself based on Alef's implementation of channels (Alef is Go's grandfather).

I tried plan9port's mk for a moment out of curiosity. I quickly ran into an annoying usability problem: it compares file mtimes with second accuracy.

https://github.com/9fans/plan9port/blob/cc4571fec67407652b03...

With sub-second build times for individual targets, this causes mk to needlessly recompile files because the target may have the same mtime as the prerequisites.