[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10600: 24.0.92; `describe-char': text properties and [Show]

From: Kevin Rodgers
Subject: bug#10600: 24.0.92; `describe-char': text properties and [Show]
Date: Thu, 02 Feb 2012 00:01:13 -0700
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv: Gecko/20120129 Thunderbird/3.1.18

On 1/28/12 10:15 AM, Juanma Barranquero wrote:
On Fri, Jan 27, 2012 at 22:43, Drew Adams<drew.adams@oracle.com>  wrote:
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,

Yes there is, or there should be a wrap, for doc strings provided by Emacs 

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.

Would it be feasible to create a temporary *Help* buffer/window/frame
with no text at all, which is "displayed" by Emacs but not rendered to
the user (i.e. not mapped by the terminal / window system), for the
purpose of querying its width and using that value when filling the real
*Help* buffer text?

Kevin Rodgers
Denver, Colorado, USA

reply via email to

[Prev in Thread] Current Thread [Next in Thread]