Hi Ingo,
> > But if we want to move from batch processing to interactive updating
> > whilst editing
>
> That probably doesn't matter because groff is simply not fast enough
> for that in the first place, even for documents of moderate size, for
> example large manual pages.
Sure it is. It's done manually at the moment by enough folks, e.g.
write the source file from vi, triggering a rebuild that has the viewer,
e.g. PDF, update. They happily wait, too long, for that to happen. The
source could be auto-written on idleness, or every now and again, and if
formatting is error free then the viewer's file is updated. The quicker
that delay when consciously waiting for it the better, but we're waiting
for it today.
> For example, on my reasonably modern laptop, formatting the ksh(1)
> manual takes more than 400ms with groff even when the input file is
> already in the buffer cache (output size: 2944 lines, 163kB).
I've gawk.1 here, no ksh, and wall-clock for various -T are
-T s ×
utf8 0.375 1.008
ps 0.461 1.239
dvi 0.372 1
pdf 2.166 5.823
utf8 gives 2,031 lines, 120,258 bytes.
> half a second keyboard latency will hardly be acceptable even for
> people who don't know professional typing at all.
You're assuming that one doesn't see the source when typing. I just
don't think that would work for troff source.
> if you want to update the "real-time" display only when the user
> request an update of the display (for example, by pressing a dedicated
> key or button, or maybe when no key is pressed for more than, say, two
> seconds)
Ah, right!
> then even making groff slower by 20% isn't really a problem: the user
> will hardly notice the slowdown if the update takes 0.5s rather 0.4s,
> or 7s rather than 5.8s.
It is a problem. The user is already waiting 0.4 s and notices. 0.5 s
would be worse. Instead, profiling could bring it down to 0.3 s. The
user would notice that too. :-)
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
