I suggest you remove all the HTML stuff from there and instead return the relative data so that some external code can write the HTML.

Good patches welcome.

There's no point making the current mixture of business logic and presentation worse.

lol. Yeah, because 5 lines of html are going to really 'make it worse'. ;) More seriously, it is api documentation. It is generally best to keep api documentation as close to the code it documents as possible. Because there is a chance this page could be 'hit often', I didn't want to have the calling code to excessive parsing of return data for display (like generating phpdoc output on the fly). An initial version returned plain text for the usage output. Maybe that was a better choice after all. In actuality, I could remove the usage() code altogether, and run phpdoc on the api file, then store that api doc separately in the web dir (maybe under /api/) or something.

In actuality, I could remove the usage() code altogether, and run phpdoc on the api file, then store that api doc separately in the web dir (maybe under /api/) or something.

That seems like a nicer option. When the class is actually used you don't really need the API on the AUR site though