Re: Summary of man-page formatting

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Sun, Nov 15, 2020 at 03:10:08 +0100, Kamil Rytarowski wrote:

> 10. I've suggested a MANWIDTH patch, which looked fine for upstream, but
> it is not guaranteed to land upstream at all or in that form.
> 
> http://netbsd.org/~kamil/patch-00287-mandoc-MANWIDTH.txt

mandoc may support MANWIDTH as an alternative to -Owidth, but that is
tangential to the the general problem of automatically adapting (or
not) to the terminal width - that logic should be handled in man(1)
and exposed to _build programs in man.conf(5).  man(1) should look at

- whether the output is a terminal or not

- what is the width of the terminal

- $COLUMNS?  I've only skimmed through what SUS says about it and I'm
  not sure of all the implications.

- $MANWIDTH override

- some kind of an upper-limit?  i.e. adapt to terminal width if less
  than some given value, but do not adapt to wider terminals. (I hate
  the default behavior of foot wide man pages in maximized terminal
  windows under linux - human vision is not very good at reading that
  (cf. very wide but very short music staff and tibetan pothi books).)

Whatever we decide the algorithm should be, it computes the number
that it then exports to the environment and programs used in _build
lines can refer to it, be it mandoc(1), nroff(1) or whatever.

As I already mentioned in an earlier mail, a simplistic example of

  _build .[1-9ln] /usr/bin/mandoc ${COLUMNS+-Owidth=${MANWIDTH:-$COLUMNS}} %s

man.conf(5) line already demonstrates this kind of logic that is
already possible (obviously it's incomplete and unwieldy and should
not be done in each _build line - but it's just an example).

-uwe