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

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

[Chong Yidong]

> 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.

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.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 6 Mar 2009 20:50:14 -0800
> Cc: 2588@emacsbugs.donarmstrong.com
> 
> > 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.

As usual, Drew, you need to calm down.  No one is jumping you, so
please don't jump others in response.

What Yidong was trying to say is this: 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.  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?

One thing we could easily do is not set COLUMNS in the environment if
pop-up-frames is being used, 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.

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.

> 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.

No one is defending this behavior.  You just have been told that
fixing it is not easy, which is a far cry.

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.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <cyd@stupidchicken.com>
> Date: Sat, 7 Mar 2009 08:20:33 -0800
> 
> > 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'.

Yidong, is this solution fine with you?

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> > 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'.
>
> Yidong, is this solution fine with you?

The width of a pop-up frame has, in general, nothing to do with the
default value of COLUMNS (or the default value that the formatter
assumes if COLUMNS is omitted).  So I don't see how this is any
improvement.

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

[Drew Adams]

> >> > 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'.
> >
> > Yidong, is this solution fine with you?
> 
> The width of a pop-up frame has, in general, nothing to do with the
> default value of COLUMNS (or the default value that the formatter
> assumes if COLUMNS is omitted).  So I don't see how this is any
> improvement.

That's why I said "please do *NOT* set COLUMNS to the current frame's width. The
problem is that it is currently being set that way; it should not be.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Drew Adams <drew.adams@oracle.com>,  2588@emacsbugs.donarmstrong.com
> Date: Sat, 07 Mar 2009 14:43:50 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > 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'.
> >
> > Yidong, is this solution fine with you?
> 
> The width of a pop-up frame has, in general, nothing to do with the
> default value of COLUMNS (or the default value that the formatter
> assumes if COLUMNS is omitted).  So I don't see how this is any
> improvement.

It is an "improvement" in the sense that, when pop-up-frames is
non-nil, Emacs 23 will behave like Emacs 20 did.

AFAICS, we started setting COLUMNS in the environment because on some
GNU/Linux system, under X, not setting it would result in over-long
lines.  To avoid that with pop-up-frames, we could set COLUMNS to the
value 80.  For a frame that is not yet created, 80 sounds like a
better default than the width of some other frame/window.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAICS, we started setting COLUMNS in the environment because on some
> GNU/Linux system, under X, not setting it would result in over-long
> lines.  To avoid that with pop-up-frames, we could set COLUMNS to the
> value 80.  For a frame that is not yet created, 80 sounds like a
> better default than the width of some other frame/window.

Right, and this handles the case where the selected frame is abnormally
wide.  But suppose the selected frame is the normal width, and has a
width of 200.  The default-to-80-columns would do the wrong thing.

I think we could use default-frame-alist to guess the number of columns.

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

[Drew Adams]

> > AFAICS, we started setting COLUMNS in the environment 
> > because on some GNU/Linux system, under X, not setting
> > it would result in over-long lines.  To avoid that with
> > pop-up-frames, we could set COLUMNS to the
> > value 80.  For a frame that is not yet created, 80 sounds like a
> > better default than the width of some other frame/window.
> 
> Right, and this handles the case where the selected frame is 
> abnormally wide.  But suppose the selected frame is the normal
> width, and has a width of 200.  The default-to-80-columns
> would do the wrong thing.
>
> I think we could use default-frame-alist to guess the number 
> of columns.

No, no, no. What is the wrong thing is to guess the number of text columns based
on *any* window or frame value - either from an existing window or frame, or
from a default alist.

As you yourself stated correctly (perhaps without meaning to):
"The width of a pop-up frame has, in general, nothing to do with the
default value of COLUMNS".

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.

Use either: (1) a user preference designed specifically for formatting the `Man'
buffer text (e.g. `Man-width') or, barring that, (2) a user preference designed
for formatting buffer text generally (e.g. `fill-column') or, barring that, (3)
a hard-coded value (e.g. 80) intended for buffer text formatting (not for window
or frame sizing).

Please do not use any value designed for windows or frames. They are irrelevant
and can only be a nuisance here.

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

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> 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 `man' facility is different from apropos or help---the text is
generated by an external formatter, not by Emacs.  If COLUMNS is
omitted, the formatter output is too long for the frame width, on at
least one (Debian) system.

Setting COLUMNS to the frame width does the right thing most of the
time, 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.  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.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>,  <2588@emacsbugs.donarmstrong.com>
> Date: Sun, 08 Mar 2009 15:06:02 -0400
> 
> Setting COLUMNS to the frame width does the right thing most of the
> time, 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.
        ^^^^^^^^^^^^^^^^^^^
Shouldn't this be pop-up-frame-alist instead?

Anyway, I wouldn't go for such adventures before Emacs 23.1 is
released.  Until then, I'd simply not set COLUMNS when pop-up-frames
is non-nil.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Anyway, I wouldn't go for such adventures before Emacs 23.1 is
> released.  Until then, I'd simply not set COLUMNS when pop-up-frames
> is non-nil.

I'm not sure we should make *any* change to this before the release.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: drew.adams@oracle.com,  2588@emacsbugs.donarmstrong.com
> Date: Sun, 08 Mar 2009 15:40:18 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Anyway, I wouldn't go for such adventures before Emacs 23.1 is
> > released.  Until then, I'd simply not set COLUMNS when pop-up-frames
> > is non-nil.
> 
> I'm not sure we should make *any* change to this before the release.

Going back to Emacs 20 behavior for pop-up-frames seems safe enough.
But it's your call.

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

[Drew Adams]

> > Anyway, I wouldn't go for such adventures before Emacs 23.1 is
> > released.  Until then, I'd simply not set COLUMNS when pop-up-frames
> > is non-nil.
> 
> I'm not sure we should make *any* change to this before the release.

Why? Why is fixing this bug an "adventure"? Just set COLUMNS to 80 in the places
you currently set it to the previous `frame-width'. There is no case where using
the previous frame's width DTRT for the text formatting, and there are cases
where it does the wrong thing. And the fix is simple.

The code after the fix will be just as good in the cases where there is no bug
today, and it will remove the bugged case. The code will also be much simpler.
This is just a case of removing inappropriate cruft.

It's one thing to put off either wish-list enhancements or complex bug fixes
before the release. I see no reason this fix can't be applied now. You claimed
the code and the fix are non-trivial, but that doesn't seem to be the case.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <2588@emacsbugs.donarmstrong.com>
> Date: Sun, 8 Mar 2009 13:17:10 -0700
> 
> > > Anyway, I wouldn't go for such adventures before Emacs 23.1 is
> > > released.  Until then, I'd simply not set COLUMNS when pop-up-frames
> > > is non-nil.
> > 
> > I'm not sure we should make *any* change to this before the release.
> 
> Why? Why is fixing this bug an "adventure"?

I used the word "adventure", and I meant the suggestion to guess the
right value for COLUMNS from default-frame-alist or
pop-up-frame-alist.  I think, even if this is correct, it's too
complex for now.

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

[Drew Adams]

> > > > Anyway, I wouldn't go for such adventures before Emacs 23.1 is
> > > > released.  Until then, I'd simply not set COLUMNS when 
> > > > pop-up-frames is non-nil.
> > > 
> > > I'm not sure we should make *any* change to this before 
> > > the release.
> > 
> > Why? Why is fixing this bug an "adventure"?
> 
> I used the word "adventure", and I meant the suggestion to guess the
> right value for COLUMNS from default-frame-alist or
> pop-up-frame-alist.  I think, even if this is correct, it's too
> complex for now.

That would be not only an adventure but misguided. Window and frame metrics and
parameters are not appropriate models for buffer text formatting.

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

[Stefan Monnier]

>> Anyway, I wouldn't go for such adventures before Emacs 23.1 is
>> released.  Until then, I'd simply not set COLUMNS when pop-up-frames
>> is non-nil.
> I'm not sure we should make *any* change to this before the release.

We should at least make this "auto adjust man width to match window
width" configurable, since (even if it were implemented correctly) it
doesn't necessarily do what the user wants.


        Stefan

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

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> We should at least make this "auto adjust man width to match window
> width" configurable, since (even if it were implemented correctly) it
> doesn't necessarily do what the user wants.

Man-width can be set to an integer.

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

[Stefan Monnier]

>> We should at least make this "auto adjust man width to match window
>> width" configurable, since (even if it were implemented correctly) it
>> doesn't necessarily do what the user wants.
> Man-width can be set to an integer.

Good point.  So let's default it to 80: this will bring back Emacs-21's
behavior and if people want the other one, they can set it to nil.


        Stefan

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

[Drew Adams]

> > 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).

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>, <2588@emacsbugs.donarmstrong.com>
> Date: Sun, 8 Mar 2009 13:16:40 -0700
> 
> > 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.

In all fairness, I mentioned it.

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

[Drew Adams]

> > > 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.
> 
> In all fairness, I mentioned it.

Sorry, I missed that suggestion on your part. Maybe that's what you meant when
you suggested perhaps going back to Emacs 20 behavior? I thought you meant that
the visible behavior, not the code, would be like that of Emacs 20. 

Yes, I guess if the code were reverted to be like Emacs 20, then more modern
`man' behavior, which uses COLUMN, would no longer have the same effect as
before.

Or maybe I'm still missing what you meant.

At any rate, omitting COLUMNS was not a fix I was suggesting. I should have left
it at that.

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

[Glenn Morris]

Chong Yidong wrote:

> The `man' facility is different from apropos or help---the text is
> generated by an external formatter, not by Emacs.  If COLUMNS is
> omitted, the formatter output is too long for the frame width, on at
> least one (Debian) system.

Not to to dredge up this overly-long thread, but a few weeks ago man was
changed to _not_ set COLUMNS under a window-system, which seems
incorrect in light of the above.

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

[Glenn Morris]

Glenn Morris wrote:

> Not to to dredge up this overly-long thread, but a few weeks ago man was
> changed to _not_ set COLUMNS under a window-system, which seems
> incorrect in light of the above.

Ignore me, I misread the code.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: drew.adams@oracle.com,  2588@emacsbugs.donarmstrong.com
> Date: Sun, 08 Mar 2009 12:08:49 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAICS, we started setting COLUMNS in the environment because on some
> > GNU/Linux system, under X, not setting it would result in over-long
> > lines.  To avoid that with pop-up-frames, we could set COLUMNS to the
> > value 80.  For a frame that is not yet created, 80 sounds like a
> > better default than the width of some other frame/window.
> 
> Right, and this handles the case where the selected frame is abnormally
> wide.  But suppose the selected frame is the normal width, and has a
> width of 200.  The default-to-80-columns would do the wrong thing.

Again, I was talking _only_ about the use-case where pop-up-frames is
non-nil.  In that case, how do you know that default-to-80-columns is
the wrong thing?  The fact that the frame selected when "M-x man" is
invoked is 200 columns wide says nothing about the frame that will be
used to display the formatted manual.

Or maybe you meant that the frame to be popped up will be 200 columns
wide.  But that is a marginal case, IMO, and it didn't work in Emacs
20, either.  So we could leave that for fixing after the release, if
ever.

When pop-up-frames is nil, the current code works well, and we don't
need to change it, IMO, certainly not before 23.1 is released.

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

[Stefan Monnier]

> width of 200.  The default-to-80-columns would do the wrong thing.

Text formatted for 200-columns is basically illegible.  So I find it
harsh to call it "the wrong thing" to use 80 columns in this context.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 2588@emacsbugs.donarmstrong.com,  Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 08 Mar 2009 15:45:46 -0400
> 
> > width of 200.  The default-to-80-columns would do the wrong thing.
> 
> Text formatted for 200-columns is basically illegible.  So I find it
> harsh to call it "the wrong thing" to use 80 columns in this context.

Agreed.

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> width of 200.  The default-to-80-columns would do the wrong thing.
>
> Text formatted for 200-columns is basically illegible.  So I find it
> harsh to call it "the wrong thing" to use 80 columns in this context.

As far as I can tell from this thread, most people agreed that Man
didn't do the right thing here, but nobody wanted to fix it, since Emacs
23.1 was too close.

Did anything more happen here afterwards?  Is this still buggy?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Juri Linkov]

> Did anything more happen here afterwards?  Is this still buggy?

Is this the same as bug#9084?

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

[Lars Magne Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

>> Did anything more happen here afterwards?  Is this still buggy?
>
> Is this the same as bug#9084?

Looks quite similar.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>>> width of 200.  The default-to-80-columns would do the wrong thing.
>>
>> Text formatted for 200-columns is basically illegible.  So I find it
>> harsh to call it "the wrong thing" to use 80 columns in this context.
>
> As far as I can tell from this thread, most people agreed that Man
> didn't do the right thing here, but nobody wanted to fix it, since Emacs
> 23.1 was too close.
>
> Did anything more happen here afterwards?  Is this still buggy?

Juri Linkov <juri@jurta.org> writes:

>> Did anything more happen here afterwards?  Is this still buggy?
>
> Is this the same as bug#9084?

And it is, I think.  Is there a particular reason why we don't just use
`frame-width' in these circumstances?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Juri Linkov]

>>> Did anything more happen here afterwards?  Is this still buggy?
>>
>> Is this the same as bug#9084?
>
> And it is, I think.  Is there a particular reason why we don't just use
> `frame-width' in these circumstances?

On 07 Mar 2009 in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2588#60
Stefan said:

  We could try to fix this: I think it would actually be desirable to pop
  up the frame immediately and then asynchronously fill it as man's output
  comes in.

On 11 Jan 2010 I posted a patch that implements asynchronous formatting
in the immediately displayed Man buffer in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5054#76
(see subthread with the subject "Man truncated", please don't merge bug#5054
because its initial report was about a different problem).

Is it time to install this patch now?

It fixes the problem with wrong widths in a new window/frame.

Though it doesn't implement formatting on the fly from the process-filter,
but maybe this could be implemented later in 24.2?

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

[Stefan Monnier]

> The problem is, AFAICS, that with pop-up-frames `man' is run _before_
> the frame to display its output is created.  To do what you want we

We could try to fix this: I think it would actually be desirable to pop
up the frame immediately and then asynchronously fill it as man's output
comes in.

This said, we could also just remove the COLUMNS business.
Who introduced this COLUMNS thingy and what was the motivation for it?


        Stefan

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

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> We could try to fix this: I think it would actually be desirable to pop
> up the frame immediately and then asynchronously fill it as man's output
> comes in.
>
> This said, we could also just remove the COLUMNS business.
> Who introduced this COLUMNS thingy and what was the motivation for it?

This is explained in the code comments: it's required to ensure that the
output of the manpage formatter has the same number of columns as the
Emacs window/frame.

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

[Drew Adams]

> > We could try to fix this: I think it would actually be 
> > desirable to pop up the frame immediately and then
> > asynchronously fill it as man's output comes in.
> >
> > This said, we could also just remove the COLUMNS business.
> > Who introduced this COLUMNS thingy and what was the 
> > motivation for it?
> 
> This is explained in the code comments: it's required to 
> ensure that the output of the manpage formatter has the
> same number of columns as the Emacs window/frame.

(1) The code does not do that correctly in the case cited: The new frame is 80
columns wide, but the text is formatted to 30 columns wide. (2) The code cannot
always know the number of columns of the to-be-created frame. (3) That number of
columns, even when the code can know it accurately, is *not pertinent* to how
the buffer should be formatted.

The code should not assume fixed window or frame sizes, or that those sizes
should govern formatting of the buffer text. That is not what is done generally
in Emacs when text is formatted (e.g. *Help*, *Apropos*,...).

The code here is nonstandard - Emacs generally does not behave like this. Some
particular group of users might (*might* - not sure) find this code helpful, but
for other users it is downright harmful. 

Please revert this unhelpful cleverness.

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

[Stefan Monnier]

>> We could try to fix this: I think it would actually be desirable to pop
>> up the frame immediately and then asynchronously fill it as man's output
>> comes in.
>> 
>> This said, we could also just remove the COLUMNS business.
>> Who introduced this COLUMNS thingy and what was the motivation for it?

> This is explained in the code comments: it's required to ensure that the
> output of the manpage formatter has the same number of columns as the
> Emacs window/frame.

Well, that part I understood, even without the comment ;-)
The question is: what was the motivation to adjust the number of columns
to that of the Emacs window/frame?


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  2588@emacsbugs.donarmstrong.com,  Drew Adams <drew.adams@oracle.com>
> Date: Sun, 08 Mar 2009 15:43:39 -0400
> 
> > This is explained in the code comments: it's required to ensure that the
> > output of the manpage formatter has the same number of columns as the
> > Emacs window/frame.
> 
> Well, that part I understood, even without the comment ;-)
> The question is: what was the motivation to adjust the number of columns
> to that of the Emacs window/frame?

Does the following comment from man.el explain it to you?

	  ;; This isn't strictly correct, since we don't know how
	  ;; the page will actually be displayed, but it seems
	  ;; reasonable.

Translation: don't have a better idea, so why not?

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

[Drew Adams]

> > Well, that part I understood, even without the comment ;-)
> > The question is: what was the motivation to adjust the 
> > number of columns to that of the Emacs window/frame?
> 
> Does the following comment from man.el explain it to you?
> 
> 	  ;; This isn't strictly correct, since we don't know how
> 	  ;; the page will actually be displayed, but it seems
> 	  ;; reasonable.
> 
> Translation: don't have a better idea, so why not?

The motivation expressed by that commentary is itself misguided.

How the page will actually be displayed (in terms of window/frame size) is
irrelevant to how to format the buffer text. That is precisely the mistake that
is being made here.

IOW, the problem is not just that the code is inadequate to the intention. The
problem is that the intention itself is misguided.

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

[Juri Linkov]

Version: 24.4.50

>> The problem is, AFAICS, that with pop-up-frames `man' is run _before_
>> the frame to display its output is created.  To do what you want we
>
> We could try to fix this: I think it would actually be desirable to pop
> up the frame immediately and then asynchronously fill it as man's output
> comes in.

Now this is implemented in bug#17831 merged with bug#2588, but to fix
the original issue of running `man' with pop-up-frames in a frame that
is 30 chars wide, required an additional change (now installed as well)
to select the window after popping up the frame to get its real width
(since display-buffer in Man-notify method `friendly' doesn't select
the window):

=== modified file 'lisp/man.el'
--- lisp/man.el	2014-05-09 07:02:00 +0000
+++ lisp/man.el	2014-07-01 23:54:32 +0000
@@ -1030,15 +1030,22 @@ (defmacro Man-start-calling (&rest body)
     ;;               ther is available).
     (when (or window-system
 	      (not (or (getenv "MANWIDTH") (getenv "COLUMNS"))))
-      ;; This isn't strictly correct, since we don't know how
-      ;; the page will actually be displayed, but it seems
-      ;; reasonable.
+      ;; Since the page buffer is displayed beforehand,
+      ;; we can select its window and get the window/frame width.
       (setenv "COLUMNS" (number-to-string
 			 (cond
 			  ((and (integerp Man-width) (> Man-width 0))
 			   Man-width)
-			  (Man-width (frame-width))
-			  ((window-width))))))
+			  (Man-width
+			   (if (window-live-p (get-buffer-window (current-buffer) t))
+			       (with-selected-window (get-buffer-window (current-buffer) t)
+				 (frame-width))
+			     (frame-width)))
+			  (t
+			   (if (window-live-p (get-buffer-window (current-buffer) t))
+			       (with-selected-window (get-buffer-window (current-buffer) t)
+				 (window-width))
+			     (window-width)))))))
     ;; Since man-db 2.4.3-1, man writes plain text with no escape
     ;; sequences when stdout is not a tty.	In 2.5.0, the following
     ;; env-var was added to allow control of this (see Debian Bug#340673).

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

[Drew Adams]

emacs -Q
 
load library cygwin-mount.el, then setup-cygwin.el:
 
http://www.emacswiki.org/emacs/cygwin-mount.el
http://www.emacswiki.org/emacs/setup-cygwin.el
 
Use /bin/bash.exe as SHELL.
 
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.  Clearly a mismatch and not what a user
expects or intends.
 
This same bug exists for Emacs 22 (e.g. 22.3) and Emacs 21
(e.g. 21.3.1).  Emacs 20 (e.g. 20.7) has no such bug.  
 
In Emacs 21, the bug occurs even without loading the two Cywin helper
libraries.  With my SHELL var set to /bin/bash.exe, I cannot test
Emacs 22 or 23 without loading those libraries, but I suspect the same
bug occurs, as it does in Emacs 21.  IOW, I don't think this has
anything to do with using Cygwin.
 
Please don't suggest customizing `Man-frame-parameters' or some such.
This should just work, normally, with no need for any user tweaking.
Setting `pop-up-frames' to non-nil does not imply that you want the
Man output (in a normal-width frame) to have the same width as the
frame that was current when you called `man'.
 
 
 
In GNU Emacs 23.0.90.1 (i386-mingw-nt5.1.2600)
 of 2009-02-01 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 6 Mar 2009 12:51:59 -0800
> Cc: 
> 
> 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.

I cannot reproduce this on my system, but I think I know why, see
below.

> This same bug exists for Emacs 22 (e.g. 22.3) and Emacs 21
> (e.g. 21.3.1).  Emacs 20 (e.g. 20.7) has no such bug.  

That's because Emacs 20 didn't set COLUMNS in the environment before
invoking the `man' program.  But that had other adverse effects on X,
see the comments in man.el where it sets COLUMNS.

> In Emacs 21, the bug occurs even without loading the two Cywin helper
> libraries.  With my SHELL var set to /bin/bash.exe, I cannot test
> Emacs 22 or 23 without loading those libraries, but I suspect the same
> bug occurs, as it does in Emacs 21.  IOW, I don't think this has
> anything to do with using Cygwin.

Actually, it does have something to do with Cygwin: I'm guessing your
man.exe comes from Cygwin, and tries to honor the COLUMNS environment
variable.  My man.exe is a natively compiled clone of the Unix `man'
command, and it doesn't pay attention to COLUMNS, so it always
produces text whose width assumes an 80-column display, no matter what
COLUMNS says.

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

[Drew Adams]

> From: Eli Zaretskii Sent: Saturday, March 07, 2009 5:58 AM
> > 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.
> 
> I cannot reproduce this on my system, but I think I know why, see
> below.
> 
> > This same bug exists for Emacs 22 (e.g. 22.3) and Emacs 21
> > (e.g. 21.3.1).  Emacs 20 (e.g. 20.7) has no such bug.  
> 
> That's because Emacs 20 didn't set COLUMNS in the environment before
> invoking the `man' program.  But that had other adverse effects on X,
> see the comments in man.el where it sets COLUMNS.
> 
> > In Emacs 21, the bug occurs even without loading the two 
> > Cywin helper libraries.  With my SHELL var set to /bin/bash.exe,
> > I cannot test Emacs 22 or 23 without loading those libraries,
> > but I suspect the same bug occurs, as it does in Emacs 21.  IOW,
> > I don't think this has anything to do with using Cygwin.
> 
> Actually, it does have something to do with Cygwin: I'm guessing your
> man.exe comes from Cygwin, and tries to honor the COLUMNS environment
> variable.  My man.exe is a natively compiled clone of the Unix `man'
> command, and it doesn't pay attention to COLUMNS, so it always
> produces text whose width assumes an 80-column display, no matter what
> COLUMNS says.

That makes sense.

That Emacs sets COLUMNS to `Man-width' is fine. The problem is apparently that
If `Man-width' is not defined (as a positive integer) then Emacs sets COLUMNS to
the current `frame-width'. That's the cause of the bug, AFAICT. Logically, the
current (soon to be previous) frame width is 100% irrelevant to `man's display.