TODO

TODO:
	Make the preset keybindings modifiable at startup.
	(eg, implement bind_key as osc)

	Copy-mode, with stack of registers and ability to edit.
	Or, maybe just have a binding (y) that dumps the current content
	of the scrollback region to a file like ~/.smtx-pid-timestamp
	Perhaps use (e) to edit the file (eg, spawn $EDITOR), then (p)
	to paste it.

	Replace select() with kqueue()/epoll()

	Enable a mode to read input and interpret key sequences.  ie,
	a filter to convert sequences like "abcdxx^H^Hef" to "abcdef"
	See: https://stackoverflow.com/questions/67415977/is-there-a-shell-utility-to-cleanup-interactive-tty-sessions



MAYBE TODO:

	Make it easy to swap bindings.  eg, so that hjkl could be used for
	scrolling in non-full screen mode.  Maybe have labelled bindings,
	so perhaps 'a or 'b would select binding a or b.  Would be simpler
	to use numbers, so 1B or 2B could select bindings 1 or 2.  It seems
	hjkl would be better for scrolling than <> and fb

	Configure bindings from a startup file or ?

	Speed things up for hidden windows.  If a pty is not visible
	on the display, we should (?) read a big chunk of data and store
	it but not actually display anything until the pty is added to
	a canvas.  This may be a bad idea since we would lose escape
	sequences, but overall I like the idea.

	Multi-key bindings (?)

	Add character in title bar to indicate mode.  Need to make
	title bar more functional in general, so this thought should
	probably be consumed by that.  Probably want to be able to send
	arbitrary format strings in through an escape sequence. Note
	that we currently can set the "title" of the window via an osc
	sequence, but that title is only a portion of the title bar.
	Probably want the ability to control the format of the title bar.
	Also, the title bar/row should probably be a subwindow rather
	than just consuming one line of the main window.  All the '-1'
	in the code gets confusing.

	Make it possible for windows to overlap. (Almost certainly don't do this.)

	Implement method to save the current layout into a register.

	Make an action on <tab> that moves to the next canvas.

	In full-screen mode, make hjkl scroll the pty.

	-1v should make the focused canvas the root and keep
	the layout below it instead of making it single screen.  Perhaps
	0v should attempt to layout all windows at one line each.

	speed up the grep() in the tests.  We read one byte at a time because
	the row validation and layout validation is crazy fragile.  If we make
	it more robust, we can probably read larger data buffers.

	Allocate a chunk of struct pty on startup, or just use a static array
	of size 512 or 1024 and stop callocing individual elements.  That should
	cleanup the implementation of new_pty() a bit.