Follow-up Comment #5, bug #68326 (group groff): You seem to have not yet seen the rest of the thread, in which I attach the configuration.nix.5 file. Accordingly, I'm going to limit my response to only things which which are not better communicated by inspecting the file itself.
> What is this "very long document"? Is it a practical one?
configuration.nix.5 is the documentation for NixOS, a popular Linux
distribution and a nascent FreeBSD distribution. It coalesces a huge number of
configuration options from a large number of sources. It is one of my most
frequently accessed man pages and, barring the use of a different type of
document reader entirely, essential for configuring one's NixOS system, since
the alternative is having a checkout of the distribution's package repository
and performing lots of very fragile text searches.
> Yes, that's because the entire page has to be addressable.
Indeed, if it is within the aim of the groff project to be able to render
arbitrarily long documents where any byte of input can affect any byte of
output, then this patch is no good. I was aware of the fact that this was at
least in theory a capability of the troff/grotty pipeline while I was
developing this patch, and as such provided the accommodation that it keeps a
buffer of at least 10k lines (16k in practice) and only flushes 1k lines at a
time, allowing any byte of input to write to any byte of output so long as
there have been at most 9k lines (15k in practice) declared to exist following
the targeted line. I assumed this was a reasonable limitation. If not, we will
obviously have to figure out something else.
The easiest compromise would be to gate this new behavior behind a command
line flag or environment variable. A potentially less hacky solution would be
to add something to the man macros which allows ending a page even in
continuous rendering mode. I actually looked into this solution before
reaching to patch grotty, but the groff macro language is a bit impenetrable
to me. If this is wanted, I'll try again.
> If you're using man-db man(1), set `MANROFFOPT=-Z`. That takes grotty out of
> the pipeline.
You seem to have responded to this below.
> I suggest you construct a man page such that most of the body text is a
> tbl(1) table using the "allbox" region option.
More or less responded above. If hundreds of thousands of lines of vertical
rule is a limitation we are working with, then so be it.
> Also, what is the application, for the practical human man page reader, of
> closing the pipe after the first ten lines and sending the output to
> /dev/null?
Of course this is not a meaningful command to a user. Please trust that I have
done the meaningful tests and have instead provided the simplest command which
has only inputs I can provide and can actually be measured easily. I have of
course tested each part of the pipeline in isolation, including with a real
pager, and verified that the numbers presented here reflect an actual user's
experience. In this case, the use of head is a rough proxy for
time-to-first-byte, sending SIGPIPE to grotty soon after it produces its first
byte. This allows the time command to provide a meaningful number, since it
will wait for its pipeline to terminate entirely before concluding its
measurement. The pipe to /dev/null also serves no purpose but to clean up the
output, but I verified that it does not affect the timing result.
I apologize for not clarifying these points in my original post. I seem to
have misjudged the standard by which contributions are assessed here. I offer
a reassurance - I have in fact spent some hours studying this codebase and its
respective communications archives in the hopes of being able to provide a
wanted, non-extractive contribution to you and your users.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68326>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
