On Fri, Apr 07, 2023 at 09:43:19AM -0500, G. Branden Robinson wrote: > At 2023-04-07T09:36:10+0300, Eli Zaretskii wrote: > > > From: "G. Branden Robinson" <g.branden.robinson@xxxxxxxxx> > [re-running *roff when a viewing a man page and resizing the terminal] > > > Seems like it shouldn't be impossible to me, but what I imagine > > > would require a little reëngineering of man(1), perhaps to spawn a > > > little custom program to manage zcat/nroff pipeline it constructs. > > > This little program's sole job could be to be aware of this pipeline > > > and listen for SIGWINCH; if it happens, kill the rest of the > > > pipeline and reëxecute it. I didn't see the rest of the thread, but one significant complexity here would be interacting with the pager to arrange for the viewing position to be returned to where it was pre-SIGWINCH; bear in mind that the pager is user-configurable (less(1) is common but not universal) and isn't directly part of man(1). > > This should be possible, but it flies in the face of the feature > > whereby formatted man pages are kept for future perusal, which is > > therefore faster: > > You're referring to cat pages. As far as I know, these are on their way > out if not already gone. Colin Watson, who has maintained the man-db > implementation of man(1)[1] for something like 20 years, can speak more > authoritatively to this, but as I understand it, the advent of resizable > xterm windows started to kill the utility of cat pages decades ago and > the increasing importance of desktop environments accelerated their > demise. Another major change in that period was the general though gradual move to UTF-8, making it somewhat unclear for some time which encoding should be preferred when rendering cat pages. (Since 2010, man-db always saves cat pages in UTF-8 and converts to the proper encoding at display time, but it took a while to settle on this approach and in the meantime there were perhaps four or five years when cat pages were commonly unavailable in practice. Even then, very few people cared enough to complain.) Furthermore, the traditional approach to saving system-wide cat pages involved having man(1) be set-id. From a modern standpoint, this was obviously problematic, and it caused both security vulnerabilities and more ordinary bugs. There are ways in which this might have been rearranged to be less of a serious problem, but if you can avoid bothering with set-id at all then that's clearly safer. My general approach to cat pages for at least the last ten years has been to put as little effort into them as possible. This has so far included not outright removing support for them (since dealing with the resulting support load, even if small, would itself be effort), but if an improvement to man(1) has some kind of degradation of cat pages as a side-effect then I usually won't hesitate to make it anyway. > ...which brings me to the other factor, of which I'm more confident: man > page rendering times are much lower than they were in Unix's early days. Indeed, and it's been the case for at least a decade that rendering times have been short enough that they can largely be considered negligible. (For most of that time my own equipment has not been particularly on the bleeding edge of performance.) > The bottom line is that, even on BSD systems (where mdoc(7) is preferred > to man(7)), a user can expect a man page to render from *roff source in > less than, say, half a second in the worst case, and the median > GNU/Linux user can expect to start reading a man page "instantaneously": The other thing to note explicitly here is that what normally matters most is the time to _start_ reading, not the time to render the whole page. My usual example for where this makes a difference is zshall(1), which is a concatenation of several other pages and comes to about 30000 lines of 80-column rendered output; on my system this takes about 0.6 seconds to render in its entirety, but typing "man zshall" nevertheless shows the first page subjectively instantaneously. -- Colin Watson (he/him) [cjwatson@xxxxxxxxxx]
