> as such they are composable in the sense that they can be used in a way the author(s) didn't think of. It's been a while since I've done any of that personally,
I do this all the time.
One of my favourite applications is a tool called "autoexpect" and I use it every time I try a new program.
What it does is this: I run a program in it's virtual terminal, and it writes a TCL script that does what I did, and puts little regex tests in for the output of that program for me. I can then edit that program (or not: sometimes the first output is fine).
Once upon a time I used to use a program called DESQview: It had a "learn" feature that allowed you to record and playback even DOS programs, so it was very easy to pick up autoexpect.
DESQview/X was their X11 server, and it also had the "learn" feature, but unless the application could be driven entirely by the keyboard, it didn't work; most similar applications I've seen over the decades since need such care for reliable "scripts".
Yes sometimes you also have the possibility of using the GUI accessibility framework to "script" the app. This is barely ok if it works, but most GUIs that I want to script were designed so that would not work at all, and it is coding that requires me work with the app instead of asking a domain expert for a recording.
autoexpect on the other hand is just text, easy to read and modify, and easy to send by email. It is hard to make a terminal application hostile to autoexpect without a great deal of work that (in the text based environment) can usually be undone just by using tmux and mosh on loopback.
> What I don't understand is why that must happen inside a terminal window where (for instance) all text must have the same font and size.
Modern (as in, since the 1980s) terminals are very capable of multiple fonts and font-sizes. I usually use a non-proportional font for coding myself.