On 5/8/23, Alejandro Colomar <alx.manpa...@gmail.com> wrote: > I couldn't notice the non-infiniteness. See the following session.
I'm not sure what you thought that test was measuring, but I'm pretty sure it's not what it was actually measuring. First, the man macros don't set their page length to INT_MAX. This was a hypothetical future change Branden proposed, which was clear in the original context but had been edited out of the conversation by this point, in part because the mention of INT_MAX itself was in a footnote, physically separated from the relevant context even in the original message floating that proposal (see http://lists.gnu.org/r/groff/2023-05/msg00033.html). So the test was, if anything, testing a potential future -man implementation. Second, the maximum page length of a document that groff can store is INT_MAX *basic units*. But, nonintuitively, a basic unit on a terminal is not a line. So looking at what happens at the INT_MAXth *line* is not telling you anything about what's happening where the page break actually occurs. (I can already hear the questions. "Why is the terminal basic unit not a line? What IS it then?" The answers are: 1. I have no idea. 2. That makes no difference to man page authors. You're unsatisfied by these. I'll elaborate. 1. Well, I still have no idea, so there's no more I can say about that. 2. One of the goals of the -man macros is to shield man page authors from having to worry about low-level roff implementation details, so that they can focus on the content of the page. But if you must know, look at the \n[.V] register in low-level roff, which the 1.22.4 manual describes as the "number of basic units per vertical unit of output device resolution." It could be different for every device, and it's easy to see the difference between the PostScript device and the terminal one: $ echo '.tm \\n[.V] is \n[.V]' | groff \n[.V] is 1 $ echo '.tm \\n[.V] is \n[.V]' | nroff \n[.V] is 40 So an INT_MAX-length terminal page would be INT_MAX / \n[.V] lines long. Though probably not even that, because a defensively coded "infinite" page length would be something like \n[INT_MAX]-2v.) And lest you're tempted to keep your test around for the day Branden does change -man's continuous rendering methodology, I bet that's when things won't go as you'd hoped. Long man pages currently have many "page" breaks, but the package goes through some calisthenics to make these breaks invisible (a trick that cannot be adopted by macro packages that also support things that are placed relative to page bottoms, like footnotes). But these calisthenics have the occasional ill side effect, especially when tables are involved, so I expect they'll be removed once man page continuous rendering is retooled in the way Branden imagines. However, once man pages expect to not have ANY internal page breaks, a hypothetical INT_MAX/\n[.V]-line page will likely go awry. If I thought that were remotely a real-world concern, I'd push back on http://savannah.gnu.org/bugs/?61453#comment7.