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

[Drew Adams]

> From: Eli Zaretskii Sent: Saturday, March 07, 2009 6:16 AM
> Emacs sets the environment
> variable COLUMNS depending on the value of Man-width.  Setting that
> variable to an integer value is supposed to cause `man' to format man
> pages to that width.  Any other value causes the man pages to be
> formatted according to the width of the current window or the
> currently selected frame (depending on whether the variable is nil or
> t).
> 
> The problem is, AFAICS, that with pop-up-frames `man' is run _before_
> the frame to display its output is created.

That's just what I was saying. It makes no sense to measure the previous frame's
width and use that. That's clearly a recipe for trouble.

> To do what you want we
> need to know in advance what would be the width of that frame.  Do you
> have any suggestions for how to pull that trick?  Pop-up frames could
> have non-default user-defined frame parameters for them, right?

This should be handled the same way it and similar things are handled elsewhere
in Emacs: If the formatting cannot be made to fit the new window or frame,
because the new window or frame size (or other parameters) is not known at the
time the `man' process is started, then just use a fixed default width - e.g. 80
chars.

And even if the new window or frame size can be known ahead of time, it's not
necessarily a good idea to base the `man' display on that. It depends on user
intention: does the user typically want fixed-size windows and frames, and
expect buffers displayed in those to fit their sizes, or does the user typically
let windows and frames fit the buffer display (or just ignore it). Different
users have different preferences.

Generally, it makes more sense for a new window or frame to not impose its
parameters on its displayed buffer. If any fitting is to be done, it is
generally the window or frame that should accommodate the buffer, perhaps
resizing itself, not vice versa. 

Where else in Emacs do we format the buffer ahead of time to fit the window or
frame that it will be displayed in? If there are any such contexts, in how many
of them do we try to do that even when the window or frame parameters are *not
known* ahead of time?

The typical approach for formatted buffers in Emacs is to format the text (e.g.
for *Help* or *Apropos*) independently of any knowledge of the window or frame
in which it will be displayed.

It would be a mistake for the Emacs `man' code to try to figure out (e.g. by
examining special-frame regexp and alist, default frame alist,...) what the new
frame parameters might be - or even whether a new pop-up frame will be used.

The proper behavior is to simply use a default text width, when nothing better
is known. Either (1) something buffer-specific, like `Man-width' or
`fill-column', if known - specific for the `Man' buffer, that is, not for the
previous buffer, or (2) just a constant, like 80. 

This is about formatting the `Man' buffer's text, so variables that apply to the
`Man' buffer's text can be pertinent. Variables that apply only to the previous
buffer or its window or frame should not be used as guides for `Man'.
 
> One thing we could easily do is not set COLUMNS in the environment if
> pop-up-frames is being used,

Yes, please do that. Please do not set COLUMNS to the current `frame-width'.

> but then you'd probably come up with
> another use-case, where pop-up frames are configured to come up with a
> width that is different from the default, and tell that this is a
> bug...  However, as this at least restores the pre-v21 behavior, it
> could be the best solution for Emacs 23.1.

No, it would not be a bug in that case, even if it might be behavior that we
could still try to improve in some way. *If* you could handle something like
non-nil `pop-up-frames' cleverly and properly in all cases, that would be OK.

If not however, the default, fall-back behavior should at least be something
reasonable, something that users might expect. There is no logical relation
between the `Man' buffer formatting and the previous frame width, so that
approach is not reasonable.

(DWIM should be only icing on an otherwise solid and stable cake. There needs to
be a cake under the icing.)

> Last, but not least, I recommend using WoMan on Windows in preference
> to `man'.  Since it's written in Lisp, it interacts better with Emacs
> features, as far as text formatting is concerned.  In particular, if
> you set woman-fill-frame to t, you will get what you want, I think.

Thanks for the info; I will keep it in mind. But it's of course irrelevant to
this bug report. This is not about finding a solution for me: customizing
`Man-width", or using Woman as a substitute, or whatever. I didn't report this
bug for myself; I reported it for Emacs.

I don't use `man' that often anymore, myself. I discovered this problem only
yesterday. I invoked `man' from a Dired buffer with Dired details hidden (and
the frame fit to the buffer), so the frame was narrow.