GNU bug report logs -
#10600
24.0.92; `describe-char': text properties and [Show]
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Wed, 25 Jan 2012 17:47:02 UTC
Severity: normal
Merged with 10127
Found in versions 24.0.91, 24.0.92
Done: Chong Yidong <cyd <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #20 received at 10600 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 27, 2012 at 22:43, Drew Adams <drew.adams <at> oracle.com> 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,
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.
> 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.
Juanma
This bug report was last modified 12 years and 279 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.