Tom Christiansen <[EMAIL PROTECTED]> writes: >>On Tue, Mar 02, 2004 at 10:01:11AM +1100, Damian Conway wrote: >>: That's a *very* interesting idea. What do people think? > >>I think anyone who does full justification without proportional >>spacing and hyphenation is severely lacking in empathy for the reader. >>Ragged right is much easier on the eyes--speaking as someone who had >>their seventh eye operation today. > > At least aesthetically, yes, it sure does look better ragged. I do > wonder why that is, though. Could it be that the unevenness of the > inserted fixed-width spacing looks rough? Or is maybe because with > long lines, one's eye might get lost, being slower to tell one line > from the next? That's certainly a reason for have shorter columns. > > In a message of mine to p5p of 4-Nov-2003 <[EMAIL PROTECTED]>, > I showed (but did not mention) how this sort of can be done without > inserting any spurious spaces whatsoever, even in a long paragraph: > >> Well, no. Mark answered so quickly after I did, and covered so much of it >> so succinctly, that I backed off again. It seems to me that he and I have >> both for a long time yearned for a perliotut; I don't believe either of us >> has ever fleshed out more than an outline, though. IO is a subject that's >> not always easy to figure out how to get the best handle on (ENOPUN). For >> one thing, it's steeped in Unix lore and tradition, and it requires either >> knowing or else teaching quite a bit of C programming that would otherwise >> be completely irrelevant to Perl. For example, when you see someone lseek >> zero bytes from the current position in Perl, you know they're remembering >> the ANSI C requirement of a seek falling between switching from reading to >> writing or vice versa. As always, you're subject to all the silly bugs in >> your libc runtime system and in your kernel; for example, we tried to have >> all buffers flushed before a fork() to avoid duplicate output in the child >> by calling fflush(0) from C, the intent being to flush data still there in >> stdio buffers. Unfortunately, on some platforms, you'll accidentally toss >> not just pending output, but also pending input. Thus the case where read >> on STDIN was called with 2 against "asdf\n", you'd still have the df\n yet >> to read get completely trounced. This is incorrect behaviour, at least as >> far as the goal of flushing pending output buffers before forking. Sadly, >> there really are a zillion little things like this, and these are just the >> exceptions, not the core functionality that you'd like to teach people for >> learning IO. Blocking and buffering are tricky; did you remember that the >> output commands can also block? Think about sending something down a pipe >> where the reader on the other end is slow or busy. That's why with select >> you also have a slot for output handles you want to know whether are ready >> for IO. It just goes on and on. It would be easier to hand out copies of >> Stevens than to write perliotut, but that's too embarrassing and annoying. > However, I fear this isn't really readily automated; sorry to interrupt. :-)
It's more fun if you do an acrostic on the left hand column. And rather harder if you perpetrate a simultaneous acrostic on the right. But I've given up on such pursuits. Not that I ever managed an ambidexterous one myself anyway. For particular values of fun, of course. -- Beware the Perl 6 early morning joggers -- Allison Randal
