bug#2588: 23.0.90; Man buffer improperly formatted - wrong width

[Drew Adams]

> > M-x set-variable RET pop-up-frames RET t
> > 
> > Resize the current frame so that it is, say, only 30 chars wide.
> > 
> > M-x man RET bash RET
> > 
> > Buffer *Man bash* is shown in a new frame. The frame has the usual
> > default width of 80 chars.  But the text of the buffer is 
> > formatted to be only 30 chars wide.
> 
> Doing what you want is not a trivial to man.el, I think.  You 
> can change the `Man-width' options if you want to fix the width.

What do you mean "doing what I want"? This is not an enhancement request for
something "I want". This is a bug report. There's no way this can be defended as
reasonable or expected behavior.

Imagine if `man' did something like that also for users who have `pop-up-frames'
= nil. You would have heard about it on day 1. Would you tell them to go and
customize the `Man-width' options to "fix the width" and get sane behavior?
Preposterous.

Fewer users use non-nil `pop-up-frames', but that's no reason that Emacs
shouldn't work reasonably with a non-nil value.

If the fix is non-trivial, as you say, it would be because the code for `man'
never should have been tightly tailored for only the nil case - too "clever" by
half. 

Why is there any relation (code coupling) between the calling frame and the
resulting `man' display? Why should the width (or other parameters) of the
calling frame affect the buffer text width of the man display - and in another
frame, to boot. Makes no sense. 

Do we do that for *Help* or *info* or NEWS or Dired or any other buffer display?
Of course not. Sure, man pages are formatted, and they need to use some set
width, but obviously the current code is able to handle different widths for
formatting. All that's needed is to stop getting the width value to use from the
calling frame.

Just look at it, to see how silly it is. I'm surprised that you would try to
defend keeping such outlandish behavior with such a lame argument.