[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: Juanma Barranquero
Subject: bug#10600: 24.0.92; `describe-char': text properties and [Show]
Date: Sat, 28 Jan 2012 18:15:45 +0100

On Fri, Jan 27, 2012 at 22:43, Drew Adams <address@hidden> wrote:

> For one thing, that is not done today, so your statement about disagreeing 
> does
> not in fact point to any _existing_ window (today) which it makes sense to use
> as the measure of the yet-to-be-displayed *Help* window.

When you say

> It's simply misguided to base the assumed *Help* window
> width on the width of any existing window.

that's a general statement, not specifically about today's windows.

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

> And in addition to doc strings, which are conventionally as described above, 
> for
> the most part dynamically composed *Help* text is filled, which uses the 
> current
> value of `fill-column'.  And that's often the default value, 70.

I think most dynamically composed *Help* text tends to be
line-oriented (i.e, it adds \n with glee), but obviously, in cases
where the text does not need careful formating, leaving it to
automatic reflowing is a valid answer. That does not mean that it is
the best, or preferred, method to write *Help* output. That depends
entirely of the output.

> So in practice it is rare (and IMO a bug) when a *Help* buffer is much wider
> than, say 80 chars.

Again, that depends on the output. There are cases where using more,
if the window is wide enough, is clearer.


reply via email to

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