bug#5566: 23.1.92; man page header ugly on narrow terminals

[Colin Watson <cjwatson@debian.org>]

On Fri, Feb 12, 2010 at 09:20:18PM +0200, Juri Linkov wrote:
> This looks like a bug in `man' from the package `man-db'.

Er, no.  groff is responsible for this output; man merely calls it.
Dan, the reporter of this bug, has a habit of attributing just about
every problem related to manual pages to man-db, leaving me to spend
maintainer time redirecting him to the right place; but that doesn't
make it so, and it would be great if other people didn't pick up the
same bad habit. :-)

> When the header line is longer than the preferred output width
> (defined by `MANWIDTH' or `COLUMNS'), the header line becomes a mess
> where letters from original header are interleaved with ^H characters.

That's the overstriking I mentioned in my earlier comment on this bug
report, to which I refer you for more detail.  It's rather unlikely to
change; this is, I suppose, a legacy of *roff's history as a physical
typesetter.

The only thing I could usefully do in man would be to pass the -P -o
option to groff, which would then pass the -o option to grotty and thus
disable some of the overstriking, but this would still leave
apparently-stray characters lying around where spaces are overstruck
with non-spaces.  I don't think it's worth it given that such lines end
up being unintelligible to all intents and purposes anyway.  As I said
in my previous comment, which I encourage you to read:

  No doubt it would be possible to fix this by extending the .TH macro
  to be able to declare some kind of fallback for use when the page
  width is too short for the normal display, but, aside from the fact
  that I have no idea where to start (this would be a groff upstream
  kind of thing), I'm not sure that the substantial effort involved is
  worth it.  I'm sure it doesn't actually cause any significant
  confusion.

> Emacs doesn't process such `man' output.  `Man-fontify-manpage' removes
> ^H's only when the character before ^H is the same as the character after ^H:
> 
>     (while (re-search-forward "\\(.\\)\\(\b+\\1\\)+" nil t)
>       (replace-match "\\1")
>       (put-text-property (1- (point)) (point) 'face Man-overstrike-face))
> 
> But in this case the characters before ^H and after ^H are different.

As I mentioned before, emacs could improve its output and make it more
consistent with typical terminal emulators by displaying X^HY as Y when
X != Y.  But I don't think it's worth much in the way of argument.

Regards,

-- 
Colin Watson                                       [cjwatson@debian.org]