You could maybe find out where the delay is by using st's Xembed support? Create a window with tabbed¹ in a tiling layout, open st in to it with "st -w <xid> -e true". If it is close to the monocle time, it is probably the other windows handling the resize event that is causing the slowdown not the layout choice.
To prove it to myself: I'm using river² and I can see a doubling-ish of startup time with foot³, iff I allow windows from heavier apps to handle the resize event immediately. If the time was a little longer(or more common) I'd be tempted to wrap the spawn along the lines of "kill -STOP <other_clients_in_tag>; <spawn & hold for map>; kill -CONT <other_clients_in_tag>" to delay the resize events until my new window was ready. That way the frames still resize, but their content resize is delayed.
You can choose the behaviour with the --shell option¹. The default behaviour is nice because it allows you to benchmark pipelines easily, but if you want to change it you can.
If we're handing out tips, then as noted in a few examples from the article hyperfine is even more useful when called with multiple commands directly. It presents a concise epilogue with the information you're probably trying to gleam from a run such as yours:
$ hyperfine -L arg '1,2,3' 'sleep {arg}'
…
Summary
sleep 1 ran
2.00 ± 0.00 times faster than sleep 2
3.00 ± 0.00 times faster than sleep 3
If your commands don't share enough in common for that approach then you can declare them individually, as in "hyperfine 'blib 1' 'blob x y' 'blub --arg'", and still get the summary.
i once used hyperfine to micro-bench elisp functions. i se $SHELL to a script that evaluated it's arguments in emacs by talking to a long-running session over a named pipe. Hyperfine runs a few no-ops with $SHELL and factored out the overhead, though it was still helpful to run a nested loop in elisp for finer results.
There is also viddy¹ for a slightly more featureful watch alternative, if you're open to a new non-default package. Being able to recall old output and search within it can be extremely useful.
Admittedly, it isn't quite a drop in replacement, but the usage is close enough that even aliasing it is unlikely to cause [many] problems.
Zsh users get a bundled curses module; see zsh/curses¹ in zshmodules(1). It is a very thin wrapper, so it works how you'd expect from other uses. There is a tetris implementation using zsh/curses that ships with zsh², and you can use it as a nice comparison to the non-curses implementation that also comes with zsh³.
I've used zsh/curses a few times to hack together little interfaces, and it is quite workable. It makes things far simpler once you start reaching for terminfo's capabilities that require you to think about state too much. A friend of mine wrote a little mblaze⁴ frontend using it, and it felt like using single mailbox mutt with less than a hundred lines of code.
I was expecting the linked project to be a loadable module too given that bash also supports them, but it is actually a little more interesting to look at given it implements a bunch of the behaviour itself on top of tput calls.
"Some sort of surfing game" immediately screams California Games¹ to me. There was surfing² plus a few other sports, and it is still good fun if you find yourself at a museum/nerd house that has one.
`git add -p` can also work for new files, it just requires you to call `git add --intent-to-add` first. After using -N/--intent-to-add you'll see that the file is registered in the status output, and -p will work exactly how like you expect.
I often find myself spiking things then breaking them back down with -N and repeated `git commit -p` to form a reasonable history. The workflow seems to really suit my mind. However, it does require some testing vigilance if you're manually editing the hunks for clarity on top of simply splitting them up.
I can implement that specific case with a couple of lines in zsh. Something like:
autoload -Uz zed
icommit() {
() {
zed $1
git commit -F $1 # -a too, if you must ;)
} =(:) # Or maybe even =(< commit_template.txt)
}
Then icommit, via zed¹, will initiate an inline editor with all the power of ZLE available. Hit C-x C-w to write and commit, or C-c to abort. Obviously, you'd want some error checking and the like².
Beauty of this basic implementation is that the keymap is fully controllable in zed as it is simply a new ZLE widget. It works with emacs or vi mode out of the box, and is fully customisable beyond that.
You could make the interface generic by writing your own ZLE widget, so that it can be called directly from within the line editor and remove the need for wrapping commands like I did above.
We've had centuries of embankment works along the Thames¹, a fair bit concentrated around the areas you'd expect to find type like this². There must be a phenomenal amount of history that was purposely covered around there. Given the scale of the works you'd have to imagine there is a significant chunk of non-London history to be found there too(the scale of granite imports from Cornwall being an obvious example).
I'm less optimistic about the possibility of more large scale digs though, as the Golden Jubilee bridge history³ points out the area is an also an exciting zone for stumbling in to unexploded ordnance and you always seem to be within few metres of a tube line or Victorian sewer.
[It is the reason I love those plucky Crossrail⁴ developers who've felt the anger from the havoc they've left across London over the few past decades. We get incredible large scale engineering works to lust over, coupled with really wacky archaeological digs tagging along for the ride.]
On a trip to London and having heard of mudlarking, I walked in one of the ‘beaches’. I immediately found an old belt belt buckle and about 20 stems from old clay pipes.
My father found a 17th century cork screw.
There must be an absolute wealth of finds along its banks.
To prove it to myself: I'm using river² and I can see a doubling-ish of startup time with foot³, iff I allow windows from heavier apps to handle the resize event immediately. If the time was a little longer(or more common) I'd be tempted to wrap the spawn along the lines of "kill -STOP <other_clients_in_tag>; <spawn & hold for map>; kill -CONT <other_clients_in_tag>" to delay the resize events until my new window was ready. That way the frames still resize, but their content resize is delayed.
¹ https://tools.suckless.org/tabbed/
² https://codeberg.org/river/river
³ https://codeberg.org/dnkl/foot