For another thing, the width of the window chosen to display the *Help* buffer
text can depend on the width of that buffer text. That we do not do that often
today is not a reason not to allow for it. That is exactly what I do with
frames, for example: I fit the frame to the buffer text, and I rely upon the
help functions to produce a reasonable buffer layout.
So you're computing the window (and frame) width from the buffer text,
and complaining that you don't like how the buffer text is
distributed, because it exceeds the maximum width you want to give to
a window or frame. But, as reflowing the buffer text according to the
window width would defeat your method, the only option left is to
chose an arbitrary limit and stick to it, even if, in some cases, a
different width is best for most users...
In many, but not all, *Help* buffers, reflowing or not reflowing their
contents is largely irrelevant. But for the output of describe-char,
the way it is now is IMHO much, *much* better that what you proposed
before (getting rid of the right-alignment of field names), and
certainly I don't think reflowing it would improve things, on the
contrary it would make them less clear.
But in that case, the key is to know what the display window is. That is a far
cry from what we do today, which is to use the current window to guess the width
of the to-be-displayed *Help* window. That makes no sense at all.
I wouldn't go as far as to say that it does "make no sense at all",
because it obviously works in many common cases. But it is erroneous,
sure.
Yes there is, or there should be a wrap, for doc strings provided by Emacs
itself.
On the contrary, I disagree on that "should be". *Help* buffers try to
give useful information, and manual reflowing is almost always better
than automatic reflowing. It fails for some narrow windows, but that's
why we use 70 chars or so as a limit. Automatic reflow to support the
likely very few users who use extremelly narrow windows seems a waste
and a step back.