Aaron Sherman writes: > Also, you pointed out that my example was hard to read, but you only > pointed out the particularly complex example (where I WANTED to > demonstrate all of the complex cases), not the simple one. The general > case would probably look like: > > H< Function | Returns > > T< foo | nothing > > T< bar | a number between 1 and 1000 > > T< baz | your program as a string >
You said that your mailer screwed up in the other one. I saw misalgined columns and some weird stuff in there and so I immediately deemed it non PODish. Now that I look more carefully and that I see this table, your proposal seems much more viable. On the other hand, Larry had a good point. Why couldn't we do: =begin table ... =end table For some sufficiently simple ...? Obviously this gives the formatter control over how the table is formatted, which is arguably a bad thing since it won't be implemented (POD tools are mostly lazy about that kind of thing). So I'm starting to like it. I do think that it should be left aligned, as it'll be verbatim text if it's indented. We might want a =begin/=end table around it anyway, to avoid making the formatters do too much bookkeeping. Luke > That's certainly no harder to read than an ASCII-art table, and provides > you with many more options in terms of presentation, accessibility and > the ability to post-process the documentation (e.g. to extract > information in an automated way). >
