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

[Juri Linkov]

>> Looks indeed ugly, but I fail to see what the
>> libwww-facebook-api-perl package could do about it?!
>
> Likewise, I agree that it's ugly, but I'm not convinced that man-db (or
> groff, which is what's really responsible here) can do anything about
> it.  If the header line just plain doesn't fit, it doesn't fit.
>
> 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.
>
> Regarding emacs' odd ^H display, which I think is the meat of Dan's bug
> report, this would appear to be essentially a bug in emacs.  grotty is
> rendering the just-won't-fit text by way of backspacing over the first
> part of the header and overstriking the middle part; it's within its
> rights to do that.  I assume that whatever (lack of) terminal emulation
> is used by M-x man isn't smart enough to handle this; perhaps it
> special-cases the overstriking used for bold and underlining, and can't
> cope with overstriking one character over a completely different
> character?

I think this is not an Emacs bug.  I can reproduce it in xterm.

When xterm is narrowed to the 50-character width, running the shell
command `man HTML::TokeParser::Simple::Token::ProcessInstruction`
displays garbage like

^H^H^H^H^H^H^H^HHTML::TokeParser::Simple::Token::ProcessInstruction(3pm)ion(3pm)

where some random letters are highlighted in bold (where the character
before ^H coincide with the character after ^H).

What we can do in Emacs is simply to remove all ^H but we can't do the
broken header line more readable.

-- 
Juri Linkov
http://www.jurta.org/emacs/