>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. :-)
--tom
PS: Ok, maybe one *could* do it, but that would still require a whole lot of
PhD-ish NLP work, and surely Damian's too engaged now for the diversion.
