Re: reformatting man pages at SIGWINCH

[Dirk Gouders]

Alejandro Colomar <alx.manpages@gmail.com> writes:

> Hi Branden,
>
> On 4/7/23 04:18, G. Branden Robinson wrote:
>> At 2023-04-06T03:10:59+0200, Alejandro Colomar wrote:
>>> Hmm, now that I think, it's probably an issue of coordinating man(1)
>>> and less(1).  I sometimes wish that when I resize a window where I'm
>>> reading a man page, it would reformat the page from source.
>> 
>> 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.
>> 
>> Maybe I thought of it this way because (I suspect) it aligns with my
>> vision I've expressed elsewhere of man(1) having unfortunately
>> aggregated two separate functions: librarian vs. renderer.
>> Historically, of course the latter function was almost vestigial, since
>> early Unix systems had no pager program and their man pages required
>> little to no preprocessing; man(1) slowly accreted into a larger thing.
>> 
>>> Of course, that might be a problem for keeping track of where I was,
>>> since lines moved around.
>> 
>> That seems like a harder problem to me.  You'd need a way for the pager
>> to communicate position information back to the mini-man renderer
>> program I envision.  Two challenges here: (1) what part of the screen
>> was the reader actually looking at?  (2) how is the pager supposed to
>> know how to map any given location on the screen back to a place in the
>> unrendered source document so it can be accurately found when the
>> document is rerendered?  These feel nearly intractable to me.  But maybe
>> I have a poor imagination.
>
> Maybe it could be done with .SH and .SS.  The heuristics to find these
> are simple.  It wouldn't be very precise, but it could try to find the
> closest (only upwards) (sub)section heading.  With some luck, .TP would
> also be helpful.

Yes, that should give nice results.  But for manual pages like git(1)
with large areas between those this becomes difficult, again.

Today, I experimented with one more heuristics, adjusting the current
position according to the proportional change of avg. line size and also
change of window dimension (horizontal) but all of those didn't get better
results than what I currently implemented (stay at the position).

Out of curiosity, I checked how firefox behaves on horizontal resizes
and comparing to some of those results, lsp is not the worst on earth ;-)

If time allows, I want to see if working with Levenshtein distances
could get exact results.  Perhaps this will turn out to be too expensive
but maybe the fact that the area to be checked is limited helps...

Regards,

Dirk