Eli Zaretskii writes:

>> From: Lluís <xscript@gmx.net>
>> Cc: 23169@debbugs.gnu.org
>> Date: Fri, 01 Apr 2016 17:13:55 +0200
>> 
>> > The usual way to fix these problems is to set Man-width to a non-nil
>> > value, as appropriate for your frame/window dimensions.  Would that
>> > solve the problem for you?
>> 
>> Thing is I don't know the width of the window that will be used, since in some
>> cases it does not exist yet:
>> 
>> +-----+                   +--+--+
>> |     |                   |  |  |
>> |     | -> M-x man man -> |  |  |
>> |     |                   |  |  |
>> +-----+                   +--+--+

> Isn't the window that man will use half of the window before the
> command?  Then you know the width in advance, because you are familiar
> with your window and frame configurations

That's only one case. Maybe display-buffer ends up creating a smaller window
(depending on its configuration hooks), or maybe it ends up reusing some other
window.


>> The ideal without breaking the asynchronicity would be to somehow display the
>> new buffer on a window before populating it (display-buffer might or might not
>> reuse a window here), calculate its window's width, set COLUMNS, asynchronously
>> call man to populate the buffer, and then really show the buffer on the previous
>> window.
>> 
>> The only problem is that creating a temporary window just to calculate its width
>> could annoy people because the contents won't be shown yet.

> Yes, that's the problem.

Martin's "pretend" argument to display-buffer could be a way out of this
conundrum. Also, here's a patch for an alternative fix.


Thanks,
  Lluis