Re: reformatting man pages at SIGWINCH

[Dirk Gouders]

Hi Alex,

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

> On 4/8/23 00:09, Dirk Gouders wrote:
>>> 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...
>
> For something simpler, you could just count words since the start of the
> section divided by total words in the section.  That should be fast, and
> I expect, also quite precise.  Hyphenating might work against you on
> this, but on average it shouldn't move you too much.

very pragmatic -- very effective, thanks for that suggestion.  I
started with implementing a simpler version of that (no counting of all
words in the section):

- Backwards count words until we reach an empty line, the section
  header or the beginning of the document

        Stop if it was the section header or beginning of the document

        Continue and just count empty lines until we reach the
        section header or the beginning of the document

This relies on the assumption that horizontal resizes don't create or
delete emty lines and it still has the weakness that manual pages
(e.g. bash(1)) contain large areas without empty lines but it's
definitely better than just staying at the position as it was before.

If it turns out to still be too weak, I could count all words between
two empty lines and set that in relation to the words from the
preceeding empty line.

But perhaps, I now learn that empty lines are by no means that constant
value that I assume...

Dirk