[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] What does the "-u" in ".tmac-u" mean?

From: Ingo Schwarze
Subject: Re: [groff] What does the "-u" in ".tmac-u" mean?
Date: Mon, 13 Nov 2017 12:45:31 +0100
User-agent: Mutt/1.8.0 (2017-02-23)

Hi Ralph,

Ralph Corderoy wrote on Sun, Nov 12, 2017 at 11:48:33AM +0000:
> Ted wrote:
>> Larry wrote:

>>> Groff is, compared to most other formatting systems, blazing-fast.
> ...
>>> it made two passes through what became a 700-900 page manual
>>> (depending on what was included) to produce a PDF in less than 2
>>> minutes.

>> I really agree with Larry! Point well stated.

> Yes, groff is fast compared to some popular alternatives.
> 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.  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).

With mandoc, formatting the same file takes 30ms, which is 13 times

I think adding 30ms to the keyboard latency may or may not be
acceptable depending on how proficient somebody is with typing, but
half a second keyboard latency will hardly be acceptable even for
people who don't know professional typing at all.  And, to be honest,
compared to what groff can easily handle and is often used for, a
3000 line (~50 page) text-only document is not really a large one.
Or even if you write a book, you will hardly want to split it into
files much smaller than that.

For example, my most recent conference presentation takes 5.8s to
render from -mm/gpresent to PostScript with groff, again with input
files already in the buffer cache.

On the other hand, 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), 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.

Of course, all that doesn't invalidate Werner's argument that it
might possibly harm people who use roff(7) as a full-blown programming
language with elaborate loops and all that.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]