Hi Bjarni, At 2026-06-21T22:33:23+0000, Bjarni Ingi Gislason wrote: > Performance is reduced,
This is an imprecise statement. Before writing to an entire mailing list about such things, you should ask yourself some questions and attempt to answer them. You can present these to the group, and the increased focus can include identification of sites in the code that merit revision or otherwise aid them to illuminate the issue. So ask yourself: By how much, quantitatively? How much does the reduction matter to end users? Is some valuable property, like rendering correctness, obtained thereby? > see bug #68145. Yes; a quick look at the Savannah ticket... https://savannah.gnu.org/bugs/?68145 ...reveals that the reported regression has been resolved in groff's Git "master" branch and that the fix is expected in the groff 1.25 release. Given those facts, what is the point of your statements above? > Requests ".nh" (no hyphenation) and ".ad l" (left adjustment only) > are overwritten, see the groff list > > "https://lists.groff.org/archive/html/groff/"; > > and messages 2026-03/msg000{57, 58, and 61}.html, > > with subject > > "groff does not respect requests '.nh' and '.ad l' in man pages". Right. These are deliberate changes, not regressions. Whether man(7)'s paragraphing macros, sectioning macros, or `TH` macro "reset" adjustment and/or hyphenation has been unspecified in *roffs prior to groff 1.24, and the behavior you'd get would vary depending on the vendor of your package. Extensive comments in groff's "an.tmac" file detail the difficulties. https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/an.tmac?h=1.24.1#n159 https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/an.tmac?h=1.24.1#n202 > The reason for all three regressions is the addition of reset macros > for man pages (an.tmac). This statement is incorrect. The reason for the performance regression reported in Savannah #68145 has nothing to do with adjustment, hyphenation, or "reset macros", but rather due to an extremely long-standing (over 35-year-old) suboptimal heap memory allocation strategy in grotty(1). The latter two issues _do_ involve "resets". > They are supposed to fix some rendering in a batch mode (two or more > man pages are processed with one command line to produce the output). Not solely that. When man(7) authors use tricks like disabling adjustment to simulate a list, as is sometimes seen in "See also" sections, the rendered result can be unsatisfactory if the document later sees a section added _after_ "See also", such as "Copyright" for instance. (Stylistically, I don't endorse that arrangement, but I try to maintain groff's "an.tmac" robustly enough that it can robustly handle stylistic preferences other than my own.) Over time, I hope that the new list enclosure macros forthcoming in groff 1.25 will prove inviting to man(7) authors such that they stop fooling with low-level requests altogether for ad hoc list construction. NEWS: * The an (man) package offers new macros to ease the formatting of lists. Enclose paragraphing macros between `LS` and `LE` to identify them as list items. Doing so can mark them as "compact", ease management of their indentation, and supply hints to the output driver to improve their rendering (as with HTML). Lists can be nested. (Sub)sectioning macro calls, and the end of the document, close all open lists. See groff_man(7) for details, and groff_man_style(7) for an example. Because these macros format no text, documents employing them risk no damage to their content if the formatter does not support them. A man(7) document author can choose either to transition to these macros, [] to manage list "compactness" and item indentation with existing man(7) package facilities, or to employ both approaches. > The "defective" rendering is caused by the input, not the macro > "an.tmac" as it was previously. Defective documents, in man(7) or any other macro package, are a simple fact of life for any *roff. > So the input should (must) be fixed to remove the regressions. Correction of all the world's man pages is out of scope for the groff project. We can enhance the formatter, its macro packages, and our documentation to describe and recommend best practices, but we can't fix people's bugs for them. Occasionally, they'll decide they just don't want to cooperate with *roff. https://gitlab.com/procps-ng/procps/blob/7ac9a0e1f5606696dc799b773d5ec70183ca91a3/ps/ps.1 > The usual (and most common) use of rendering man pages is using just > one man page, That's true. > man <man page> or man <number> <man page> > > not many simultaneously with one command line. Yes. So? > When more than one input file is used with the "man" command, each man > page is rendered with its own command groff-line. What you describe is true of man-db man(1), as I understand it. It is not necessarily true of other man(1) programs, past, present, or future. There is no contract or standard binding such programs to behave as you suppose. > Why shall (must) a special case of rendering be obligatory for all > other cases, which are much more common. Because it's computationally cheap, imposes a lower maintenance burden on me (and, notionally, other groff developers), and imposes no ill side effects on well-composed man(7) documents. > Besides the implemented "batch processing" is simply wrong, bad, By what standard? I find it valuable to produce documents such as... https://www.gnu.org/software/groff/manual/groff-man-pages.pdf ...and Alex Colomar of the Linux man-pages project similarly finds such batch processing of value. https://www.kernel.org/pub/linux/docs/man-pages/book/man-pages-6.18.pdf Moreover, for output formats like PDF, as seen above, batch rendering makes internal document hyperlinking tractable, even straightforward, with no additional effort required of the man(7) document author. > more expensive How are you measuring expense? What weight do you assign the advantages of the processing time involved in producing internal hyperlinks for PDF documents? If you want to truly minimize a program's consumption of your computer's CPU and memory resources, you can not run it at all. > and based on lack of considering the consequences. My development practices produce a copious documentary record of decisions groff developers have taken, including considerations of trade-offs and cost/benefit analyses. Your charge must be supported by evidence, or it is merely an insult. > No quality control (or assessment) is present. Again, without supporting evidence, your claim is just a sneer. > N.B. > > Try "man ul" or "man 1 ul". On my system, I see nothing remarkable, and groff produces no warnings even when these are maximally enabled. $ groff --version | head -n 1 GNU groff version 1.24.1 $ zcat $(man -w ul) | groff -Tutf8 -b -ww -P-i -rU1 -rCHECKSTYLE=4 -man - > The rendering is forced to be adjusted at both margins and hyphenated, > which shows a bad rendering in the last part. I see no "bad rendering". Perhaps I have different version of the man page installed. $ zcat $(man -w ul) | groff -Tutf8 -b -ww -P-i -rU1 -rCHECKSTYLE=4 -man - | sed -n '/HISTORY/,$p' HISTORY The ul command appeared in 3.0BSD. BUGS nroff usually outputs a series of backspaces and underlines intermixed with the text to indicate underlining. No attempt is made to optimize the back‐ ward motion. SEE ALSO colcrt(1), login(1), man(1), nroff(1), setenv(3), terminfo(5) AVAILABILITY The ul command is part of the util‐linux package and is available from Linux Kernel Archive. util‐linux September 2011 UL(1) If the version of ul(1) on your system renders poorly, then as you noted above... > the input should (must) be fixed to remove the regressions. You therefore might consider reporting the defect you observe to the maintainers of the document. Have you considered reviewing your arguments for internal consistency before presenting them to this list? Regards, Branden
signature.asc
Description: PGP signature
