libtickit terminal size handling

I've recently been working on the Window layer in the C library libtickit (a migration to C from my Tickit perl distribution). It's very-almost ready now - I think we have all the code and tests ported from Perl (with the single exception of the extended drag-and-drop events whose names start "drag_..."). I haven't yet done the docs though.

I've also been adding/fixing a few other bits in the core code. Two new term-related functions make actually writing programs a little neater:

void tickit_term_observe_sigwinch(TickitTerm *tt, bool observe);
TickitTerm *tickit_term_open_stdio(void);

This latter convenience function makes all the examples a few lines shorter, and while it's at it, enables the SIGWINCH behaviour. That ensures that the TickitTerm instance actually sends EV_RESIZE events when the terminal is resized. Previously C programs couldn't actually detect that one; it was done in the Perl layer using a handler on $SIG{WINCH}.


Meta-Meta Documentation

When any project of mine gets over a certain size and people start actually using it for things, inevitably people ask me for more documentation. Often there is a problem here in that I'm never really quite sure what to write about. I find it very hard to provide tutorial-style documentation "up-front" explaining the hows and the whys (as compared to reference-style docs, which just lists all the pieces that exist).

Let me give a random example: Consider Parser::MGC, a base for writing grammar parsers. Someone might want to use this for parsing some sort of expression language, and they'd find a lack of explaining how to do that. It's not that I don't know how to explain that, it's simply that it hasn't occurred to me to write that documentation as a discrete subject. If they'd ask me on IRC I could explain at great length, because they'd given me that initial impulse to give them an answer. But at some point someone will say "Well why isn't that written in documentation?" or "You should write a tutorial", and the same cycle of conversation will usually end with something like

But I don't know what documentation to write for you.

I have sometimes asked people to explain to me what documentation they want, and usually people don't like doing that because they feel since they don't already know the answers, they can't provide the questions. This article is my attempt to break out of that cycle.

Here now then is my rather direct plea to anyone who would ask me for more documentation. Here is your documentation on how to document what documentation I should write - a meta-meta-document:

If you explain to me what problems you want to solve, or what situations you want documentation for, that's a good start. It would be better if you can provide me some introduction text around your problem, your background, and then I can write something better for you specifically, that still stands nicely on its own.

But, here's the killer revelation:

If you write some documentation wherein you write the English waffly-wordy bits that explain the background of the problem and introduce the reader to the background context of the code, and then write a block of code that just says
banana banana banana
then I will find that about a hundred times easier to write. All I have to do is fill in that blob of perl code, and hey presto; there's your documentation.

I know this is a lot to ask of people, and I don't imagine it will happen very often, but that would be by far the fastest quickest way to get more documentation out of me.