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

["Drew Adams" <drew.adams@oracle.com>]

> > Please do not set COLUMNS to any value that is designed for frames -
> > that includes `default-frame-alist'. COLUMNS is about buffer text
> > formatting, not about frame sizing.
> >
> > The formatting width for the `Man' buffer, like that of for 
> > the *Help* buffer or the *Apropos* buffer or others, should
> > have *nothing to do* with the width of any window or frame
> > parameter - existing or default.

The point of that sentence, which your response below ignores, is that window
and frame metrics are *irrelevant* to text formatting of the `man' output.

> The `man' facility is different from apropos or help---the text is
> generated by an external formatter, not by Emacs.

So what? That doesn't change the principle. At most, it changes how the text
formatting is done - not what should be used to determine which formatting is to
be used. 

You are twisting things, here. The issue is not who (`man' vs Emacs) actually
formats the text. The issue is what should be the source for the COLUMNS value.
*Help* and *Apropos* use fixed values; they do not use a value that depend on
what they guess the displaying window or frame might be like.

> If COLUMNS is omitted, the formatter output is too long
> for the frame width, on at least one (Debian) system.

No one but you has mentioned *omitting* COLUMNS. That is a red herring. The
question is what value should be used for COLUMNS - that's all.

Where should that value come from? You don't address that. This omission
suggests you think that just because COLUMNS needs to be defined, it should be
taken from a frame parameter. That doesn't follow, at all.

> Setting COLUMNS to the frame width does the right thing most of the
> time,

Nonsense. You haven't even named one context for which it does the right thing,
let alone supported the assertion that it DTRT most of the time. (Where "most of
the time" can only mean most of the time that COLUMNS is not defined otherwise.)
I would argue that whenever `frame-width' is used here it either has a negative
effect or it has no effect. AFAICT, it never adds anything useful.

And, in any case, "most of the time" is not good enough, if the behavior is, as
it is, badly bugged for other cases.

Besides, there is absolutely no reason for this behavior, even in the cases
where it does not present a problem. It is illogical and un-Emacs to couple the
text formatting to some window or frame size.

> and covers more cases than a hardcoded value.  It's true that it
> can fail for the pop-up-frames case, and we can work around that by
> using default-frame-alist.

No, that is precisely the wrong thing to do. That continues the mistake of using
a frame parameter for text formatting decisions. Completely uncalled for.

> Certainly, it's always possible to come up
> with a special setup that makes this heuristic fail.  But if you're
> setup is so special, just set Man-width and be done with it.

This has nothing to do with my setup. Stop trying to make this sound like
something special for weird ol' Drew. I told you that my interest here is fixing
Emacs, not customizing my setup. And I mentioned that I rarely use `man' myself
nowadays. This has nothing to do with my own use of Emacs. This becomes ad
hominem argument. This is not about Drew.

You are distorting the discussion, throwing out red herrings, ignoring
straightforward arguments made by others, and trying to give the impression that
this is just a corner case - or worse, just a case of customization due to odd
personal preferences or individual setup.

Please listen: The buffer text formatting should not be based on a window or
frame measurement or setting. COLUMNS should be based on user choice (e.g.
`Man-width') or, failing that, on some buffer text-formatting setting (e.g.
`fill-column' or 80).