bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Drew Adams]

In `describe-char', the max width of the displayed output is calculated
based on the width of the current window.  This makes zero sense,
especially when *Help* is displayed in a separate frame, and that case
includes but is not limited to the case where *Help* is a
special-display buffer.
 
To see this, make *Help* a special-display buffer, then, in some other
frame and buffer, do `C-u C-x ='.  Make that frame narrower and do it
again.  Repeat.  At some point of sufficient narrowness, you will see
this kind of (bizarre) formatting:
 
        character:
                   c (99, #o143, #x63)
preferred charset: ascii
                   (ASCII (ISO646 IRV))
       code point: 0x63
           syntax:
                   w  which means: word
         category:
                   .:Base, L:Left-to-right (strong), a:ASCII, l:Latin, r:Roman
      buffer code: #x63
        file code: #x63
                   (encoded by coding system undecided-unix)
          display:
                   by this font (glyph code)
    uniscribe:-outline-Lucida
Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1 (#x46)
...
 
Note the unnecessary newlines after `character:', `syntax:', and
`category:'.  This is uncalled for.  There is no reason to base
the display output width on the window width of the current buffer -
no relation.  That is so even in the case where the same frame is
used.  Please revert this annoying and unnecessary cleverness.

In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600) of 2011-11-21 on MARVIN
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-2.10.1/include --ldflags
 -LD:/devel/emacs/libs/gnutls-2.10.1/lib'
 

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 24 Nov 2011 10:29:44 -0800
> 
> There is no reason to base the display output width on the window
> width of the current buffer - no relation.

How else would you suggest to make the text aligned nicely?  That's
the intent, I believe.

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Drew Adams]

> > There is no reason to base the display output width on the window
> > width of the current buffer - no relation.
> 
> How else would you suggest to make the text aligned nicely?  That's
> the intent, I believe.

Well, the bug describes how "nicely" the text is laid out now.

Keep it simple.  Do not try to second-guess where *Help* will be displayed or
how wide its window might be.  Keep the text in *Help* to the normal max width,
as much as possible.

There is nothing wonderful about this:

             foo: jkjkj
  something-else: lllmmnlkjlj
     and-another: hhhhhmlkklmkklj
 and-yet-another: 232iulkjlikjkm

This is just as readable:

 foo:             jkjkj
 something-else:  lllmmnlkjlj
 and-another:     hhhhhmlkklmkklj
 and-yet-another: 232iulkjlikjkm

So is this:

 foo            : jkjkj
 something-else : lllmmnlkjlj
 and-another    : hhhhhmlkklmkklj
 and-yet-another: 232iulkjlikjkm

And so is this:

 foo: jkjkj
 something-else: lllmmnlkjlj
 and-another: hhhhhmlkklmkklj
 and-yet-another: 232iulkjlikjkm

And so are other ways to display such info.  Besides, these are different fields
with different meanings - we are not aligning decimal points here.  Each field
is essentially a heading/term followed by a description.  This is a _description
list_.

There are many, many ways to display such info, and which do not require
calculating the window width.  We do the same kind of thing in our online
manuals, when we describe functions etc., and even when we list menu items.

Be less "clever".  Be more helpful to more users, who can have different
preferences for displaying *Help*.

Do not suppose that people use windows the same way you do.  *Help* is very
general, and is meant to be.  It needs to be versatile and simple, not cleverly
trying to adapt itself to the current window config.

Misguided - should be rethought along the lines of traditional Emacs *Help*
output - straightforward and simple.

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Juanma Barranquero]

On Thu, Nov 24, 2011 at 20:08, Drew Adams <drew.adams@oracle.com> wrote:

> There is nothing wonderful about this:
>
>             foo: jkjkj
>  something-else: lllmmnlkjlj
>     and-another: hhhhhmlkklmkklj
>  and-yet-another: 232iulkjlikjkm

FWIW, perhaps there's nothing wonderful about it, but to me is by far
the most readable of the options you mention.

    Juanma

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Drew Adams]

> > There is nothing wonderful about this:
> >
> >             foo: jkjkj
> >  something-else: lllmmnlkjlj
> >     and-another: hhhhhmlkklmkklj
> >  and-yet-another: 232iulkjlikjkm
> 
> FWIW, perhaps there's nothing wonderful about it, but to me is by far
> the most readable of the options you mention.

Then please make it DTRT for all window configs, including a separate *Help*
frame.  

That's the bug reported.  If you don't want to simplify things (for both
maintenance and users), then please jump through whatever clever hoops you like,
so that something reasonable (for all configs) results.

And while you're at it, maybe you would like to change all of the other
description lists throughout the Emacs doc, to fit the same pattern...

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Juanma Barranquero]

On Thu, Nov 24, 2011 at 21:52, Drew Adams <drew.adams@oracle.com> wrote:

> Then please make it DTRT for all window configs, including a separate *Help*
> frame.
>
> That's the bug reported.  If you don't want to simplify things (for both
> maintenance and users), then please jump through whatever clever hoops you like,
> so that something reasonable (for all configs) results.
>
> And while you're at it, maybe you would like to change all of the other
> description lists throughout the Emacs doc, to fit the same pattern...

I do not intend to do anything with this bug report. I'm just stating
my opinion, as you did.

    Juanma

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <10127@debbugs.gnu.org>
> Date: Thu, 24 Nov 2011 11:08:59 -0800
> 
> > > There is no reason to base the display output width on the window
> > > width of the current buffer - no relation.
> > 
> > How else would you suggest to make the text aligned nicely?  That's
> > the intent, I believe.
> 
> Well, the bug describes how "nicely" the text is laid out now.
> 
> Keep it simple.  Do not try to second-guess where *Help* will be displayed or
> how wide its window might be.  Keep the text in *Help* to the normal max width,
> as much as possible.
> 
> There is nothing wonderful about this:
> 
>              foo: jkjkj
>   something-else: lllmmnlkjlj
>      and-another: hhhhhmlkklmkklj
>  and-yet-another: 232iulkjlikjkm
> 
> This is just as readable:
> 
>  foo:             jkjkj
>  something-else:  lllmmnlkjlj
>  and-another:     hhhhhmlkklmkklj
>  and-yet-another: 232iulkjlikjkm
> 
> So is this:
> 
>  foo            : jkjkj
>  something-else : lllmmnlkjlj
>  and-another    : hhhhhmlkklmkklj
>  and-yet-another: 232iulkjlikjkm
> 
> And so is this:
> 
>  foo: jkjkj
>  something-else: lllmmnlkjlj
>  and-another: hhhhhmlkklmkklj
>  and-yet-another: 232iulkjlikjkm

Your suggestions won't work with variable-size characters and
variable-pitch fonts.  The original code uses display features to
align the text even in those cases, because this command is _about_
displaying characters with various fonts, so it cannot just DTRT in
95% of cases, it needs to work in 100%.

> There are many, many ways to display such info, and which do not require
> calculating the window width.  We do the same kind of thing in our online
> manuals, when we describe functions etc., and even when we list menu items.

None of the manuals needs to cope with arbitrary characters and
arbitrary fonts.  The on-line manuals are actually quite restrictive
in the repertory of character sets and typefaces they support.

> Be less "clever".  Be more helpful to more users, who can have different
> preferences for displaying *Help*.

Be less "clever".  Be more helpful to Emacs development by actually
understanding the underlying the problems and the current solutions
before you judge them.  Do not assume that whoever wrote the code did
that out of sheer "cleverness".

To summarize: I agree that this command should be fixed for the use
case when the window width is very different from the default one.  I
just don't think the direction you propose for the solution is the
right one.

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]

> > Keep it simple.  Do not try to second-guess where *Help* 
> > will be displayed or how wide its window might be.  Keep
> > the text in *Help* to the normal max width, as much as possible.
> 
> Your suggestions won't work with variable-size characters and
> variable-pitch fonts.

Then please fix the BUG some other way, if you don't like my suggestions about
fixing it.

But I hope you realize that there are millions of web pages that use description
lists with variable-size chars and variable-pitch fonts, and most of them (the
better ones, typically) do not pay any heed to the browser window width.

Similarly, all of Emacs's own manuals, as viewed in Info through Emacs, use
description lists and the like all over the place, though it is true that they
do not, by default, use variable-width fonts.

They do NOT try to calculate the window width, AFAIK.  Like the *Help* display,
they aim for a maximum line length, instead of trying to divine the window width
with a crystal ball and fiddling with right alignment.

Besides that, for the most part changing the font does not make Info horrible.
In fact, a variable-pitch font can be quite readable for the manuals - see
screenshot attached.  (No, I am not proposing a var-width font by default for
Info.  The point is about description lists.)

I don't think you'll find ONE place where Info tries to format such lists the
way you seem to support, guessing the window width for the display and
_right-aligning_ the terms that are described.  It doesn't do that for menu
items either.

I think you're missing the point about the items listed in this particular
*Help* display constituting what is essentially a description list: term + its
description.  There is nothing earth-shaking about such a list, and it is
perfectly capable of handling fonts and chars of all types and sizes, AFAIK.

> The original code uses display features to
> align the text even in those cases, because this command is _about_
> displaying characters with various fonts, so it cannot just DTRT in
> 95% of cases, it needs to work in 100%.

So make it work in 100% - agreed.  So far, it does not - voir le BUG.

You seem to be grasping at straws to defend the status quo.  My suggestion is to
just create a list of terms, with each term followed by its description.  Put
that description in any font you like (and likewise the term, if appropriate -
e.g. the char).  Not a problem AFAICT.  But just a suggestion.

Again, this is a bug report - it's up to you how you fix the bug.

> > There are many, many ways to display such info, and which 
> > do not require calculating the window width.  We do the
> > same kind of thing in our online manuals, when we describe
> > functions etc., and even when we list menu items.
> 
> None of the manuals needs to cope with arbitrary characters and
> arbitrary fonts.  The on-line manuals are actually quite restrictive
> in the repertory of character sets and typefaces they support.

See above.  See the World Wide Web.

My advice, again: keep it as simple as possible ("possible" includes satisfying
any special font needs or whatever).  But feel free to ignore the suggestion.

> > Be less "clever".  Be more helpful to more users, who can 
> > have different preferences for displaying *Help*.
> 
> Be less "clever".  Be more helpful to Emacs development by actually
> understanding the underlying the problems and the current solutions
> before you judge them.  Do not assume that whoever wrote the code did
> that out of sheer "cleverness".
> 
> To summarize: I agree that this command should be fixed for the use
> case when the window width is very different from the default one.  I
> just don't think the direction you propose for the solution is the
> right one.

Glad you agree.  And not just for some windows with widths different from the
default width.  It should be fixed, in particular, for the case reported.

If you prefer complicated, clever, and clumsy to simple and straightforward,
fine.  But please fix the broken use case reported, one way or another.   

Sorry to have proposed simple ways to fix the bug, which don't stand up to your
quality standard.  And I am delighted to hear that you have a higher standard.
Looking forward to a great fix.  Thx.

[-- Attachment #2: throw-info-var-font.png --]
[-- Type: image/png, Size: 73396 bytes --]

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <10127@debbugs.gnu.org>
> Date: Fri, 25 Nov 2011 07:25:21 -0800
> 
> If you prefer complicated, clever, and clumsy to simple and straightforward,
> fine.  But please fix the broken use case reported, one way or another.   
> 
> Sorry to have proposed simple ways to fix the bug, which don't stand up to your
> quality standard.  And I am delighted to hear that you have a higher standard.
> Looking forward to a great fix.  Thx.

You just can't miss an opportunity to offend, can you?

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Drew Adams]

>>> I agree that this command should be fixed for the use
>>> case when the window width is very different from the
>>> default one.  I just don't think the direction you
>>> propose for the solution is the right one.

I don't have any problem with your picking a different solution, as I said.  No
offense taken - no problem.  On the contrary - the better the solution, the
better.  I have no problem with right-aligned field headers, if that can be made
to work correctly (no bug).

>> Sorry to have proposed simple ways to fix the bug,
>> which don't stand up to your quality standard.  And I
>> am delighted to hear that you have a higher standard.
>> Looking forward to a great fix.  Thx.
> 
> You just can't miss an opportunity to offend, can you?

Please stop the ad hominem attack.  I meant no offense.

I really am delighted that you want to fix this in the best way possible.  My
suggestions for fixing it were only that: suggestions.  I have no problem if you
ignore them, as I said.  My only concern is that the bug be fixed, not how the
fix is implemented.

I tried to help by giving reasons why I think it might not be necessary to
figure out the window width and right-align the field headings.  I tried to
respond to your claim that such complicated fiddling is necessary because
variable chars and fonts are involved.

For that, I tried to show that a simple description list can work with
variable-size chars and variable-pitch fonts.  I tried to show that the manuals
can in general deal with arbitrary chars and fonts in their equivalent of
description lists.  I tried to point out that the WWW commonly uses simple
description lists with variable chars and fonts, and without any need for
window-width calculation or right alignment.

I think the problem might be simpler than you think.  You apparently think it is
harder than I think.  Fair enough.

I told you why I think it can be simplified.  You told me why you think it's
inherently hard: variable chars and fonts.  I answered that argument - the only
one you gave, AFAICT.

But you did not respond to any of my arguments or point out why ordinary
handling of description lists would not be sufficient here.  Instead of
technical discussion and argument, your only reply was a personal attack.

Before that, you lambasted me for not "understanding the underlying the problems
and the current solutions".  Fair enough, if true.  But you haven't presented
any of those problems, beyond saying that we need to support variable chars and
fonts.

I responded to that, the only argument you gave in favor of needing a
complicated solution.  Where's the beef?  What are the underlying problems I
don't understand?

It's true that I don't really need to understand the problems or try to suggest
something that I hope might help.  My role in reporting the bug is done, and I'm
glad you agree that it needs to be fixed.

Based on your understanding, you seem bent on a harder, but perhaps better,
solution than I had in mind.  I'm OK with that - it's your call.  My suggestions
of a simpler approach were only intended to help.

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <10127@debbugs.gnu.org>
> Date: Fri, 25 Nov 2011 11:41:16 -0800
> 
> > > If you prefer complicated, clever, and clumsy to simple and
> > > straightforward, fine.  But please fix the broken use case
> > > reported, one way or another.
> 
> > > Sorry to have proposed simple ways to fix the bug, which don't
> > > stand up to your quality standard.  And I am delighted to hear
> > > that you have a higher standard.  Looking forward to a great
> > > fix.  Thx.
> > 
> > You just can't miss an opportunity to offend, can you?
> 
> Please stop the ad hominem attack.  I meant no offense.

I cannot possibly know what you meant.  All I have is what you wrote.
If you think the above has no offense, I suggest to get a second
opinion from someone neutral.  I submit that it has arrogance and
contempt for others' work and opinions all over it.  Coupled with the
fact that you use this abusive style over and over and over again,
it's a small wonder that you succeeded to alienate most everyone here.

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <10127@debbugs.gnu.org>
> Date: Fri, 25 Nov 2011 11:41:16 -0800
> 
> I really am delighted that you want to fix this in the best way
> possible.  My suggestions for fixing it were only that: suggestions.
> I have no problem if you ignore them, as I said.  My only concern is
> that the bug be fixed, not how the fix is implemented.

OK, let's give it another try.

No matter how you format the various fields of the information
displayed by "C-u C-x =", it will eventually happen that the window is
not wide enough to display something like this:

   foo bar: bla-bla-bla yak-yak-yak

in a single screen line.  When this happens, the current code does the
following:

  . it inserts a newline after the colon
  . it indents to the column just past the one occupied by the colon
  . it then inserts the remaining text at that point

The result is roughly this:

    foo bar:
             bla-bla-bla yak-yak-yak

There are several possible ways to change this.  One is just
displaying the value disregarding the window width, producing a
continuation line:

    foo bar: bla-bla-bla yak-\
 yak-yak

Another is to force word-wrap in the *Help* buffer, resulting in

    foo bar: bla-bla-bla \
 yak-yak-yak

Yet another is do the equivalent of M-q, with this result:

    foo bar: bla-bla-bla
             yak-yak-yak

There are others, I'm sure.

So which one is the best?

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 6573 bytes --]

> No matter how you format the various fields of the information
> displayed by "C-u C-x =", it will eventually happen that the
> window is not wide enough to display something like this:
>    foo bar: bla-bla-bla yak-yak-yak
> in a single screen line.

Agreed, assuming a conventional line length limit for a *Help* buffer (which I
support).

In fact, that is already the case.  I see this, for instance:

          display: by this font (glyph code)
    uniscribe:-outline-Lucida
Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1 (#x25)

The `display:' field has the normal alignment for the colon.  The `uniscribe:'
field does not.  Some leading whitespace was apparently sacrificed to try to
compensate a little, but it is not sufficient.  The text in the line is just too
long - it violates the max *Help* line length convention.

> When this happens, the current code does the following:
>   . it inserts a newline after the colon
>   . it indents to the column just past the one occupied by the colon
>   . it then inserts the remaining text at that point
>
> The result is roughly this:
>     foo bar:
>              bla-bla-bla yak-yak-yak

FWIW, It does not seem to do that in the case I just mentioned.  If it did, the
result would presumably be this:

          uniscribe:
                    -outline-Lucida
Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1 (#x25)

> There are several possible ways to change this.  One is just
> displaying the value disregarding the window width, producing a
> continuation line:
>     foo bar: bla-bla-bla yak-\
>  yak-yak

That violates the *Help* line-limit convention (already the case, for a font).
And it works against frame/window fitting to the buffer text.

> Another is to force word-wrap in the *Help* buffer, resulting in
>     foo bar: bla-bla-bla \
>  yak-yak-yak

Word-wrapping is a bad idea here, IMO, as some of these fields do not have a
notion of "word", and whitespace can be significant in some cases (e.g. fonts).

> Yet another is do the equivalent of M-q, with this result:
>     foo bar: bla-bla-bla
>              yak-yak-yak

Again, that will be wrong in some cases, particular cases like a font name,
where whitespace in the value is significant.

> There are others, I'm sure. So which one is the best?

First, a comment wrt my own use case, which has a separate frame for *Help*.  In
my case, having lines that are longer than the usual limit is not a problem.  My
setup automatically fits the frame to the buffer text, no matter how wide (up to
the screen width or a user-defined limit).

See attached screenshots for examples.  With the current behavior, the longest
line in the example help text is 93 chars.  That's too long, IMO, but it is
still OK wrt frame-fitting and practical use, as can be seen.

(Screenshots *help.png and *help-1.png both show what current, vanilla Emacs
gives, with different widths for the window where you hit `C-u C-x ='.)

That's an aside, but it's worth mentioning.  The line-length limit is not so
pertinent in my use case.  But yes, I would prefer that *Help* always impose its
conventional line length limit.

(Note that the `preferred charset' and `file code' fields are already
wrapped/multiline, presumably on purpose.  And the char code properties and text
properties fields are likewise already multiline.  I'm guessing these are all
special-cased in the code - dunno.)

Wrt which is best: IMO, again, best is probably to keep it simple.

Without knowing or thinking much about the particular field values possible
(thus ignoring special-casing), I'd say we should:

1. Hard-wrap (i.e., insert a newline) at the *Help* line-width limit (70?).

2. Add an extra newline after a (final) multiline value, to visually separate
the multiline field from the next field.

(A multiline field includes a continuation-line field, from #1.)

E.g.:
     foo bar: bla-bla-bla yak-
yak-yak

Yes, any use of continuation lines (whether inserting newlines or not) can be
ugly, making it difficult to distinguish field headings from continued values.
The same problem can arise with other choices, though not necessarily to the
same degree.  #2 hopes to help with this.

So far, this assumes that you choose to continue with the current
right-alignment of field headings (names).  If instead you follow my suggestion
of doing something simpler then I think things could be clearer.  See the other
attached screenshots (*help-[2345].png), all of which follow this same general
suggestion:

1. A hard line-length limit for all *Help* buffers.
2. A newline after each field (i.e., after its last value line).
3. Field headers left-aligned, followed by a colon.
4. Field values (but not their continuation lines) indented
   wrt field headers.

#2 could be relaxed, e.g., inserting the newline only if the field value is
multiline.

In screenshot *help-2.png I did not reformat the last two fields, which
themselves are lists, and I did not reformat `category:' (didn't realize it was
a list).

Formatting of list values could be done the same way, using an additional
indentation level.  The other screenshots (*help-[345].png) show that.
Screenshot *help-5.png combines this with the relaxation described for #2.

(Note that I also moved the `customize what to show' link before the colon, as I
guess it is not part of the field value itself.  I.e.:

  Character code properties (customize what to show):

vs

  Character code properties: customiize what to show
)

Yes, there is a tradeoff to some extent between (a) readability and compactness,
on the one hand, and (b) flexibility and ability to represent any field value
unambiguously and without "jumps" (see below) or overrunning the line-length
limit.

I think screenshot *help-5.png compares favorably with the current Emacs display
(*help[1].png).  But some more complicated special treatment like what is done
now could be factored in if you prefer, to perhaps improve the
formatting/readability (dunno).  Again, I'm not against any complicated
treatment, as long as the result is good for users (readable, flexible).

Comparing just screenshots *help-5.png and *help[1].png:

 38 lines vs 27/30 (could be 26 with a wide starting window)
 no long lines vs one
 no "jumps" (extra newlines after headers) vs one/four
 consistent vs inconsistent treatment of fields & subfields
 no need to divine the target window's width vs guessing

Wrt the "jumps": hitting `C-u C-x =' in a narrower window produces more jumps in
current Emacs.  It would never produce jumps with the suggested formatting.

HTH.

[-- Attachment #2: throw-char-desc-help.png --]
[-- Type: image/png, Size: 36892 bytes --]

[-- Attachment #3: throw-char-desc-help-2.png --]
[-- Type: image/png, Size: 41654 bytes --]

[-- Attachment #4: throw-char-desc-help-3.png --]
[-- Type: image/png, Size: 45727 bytes --]

[-- Attachment #5: throw-char-desc-help-4.png --]
[-- Type: image/png, Size: 44520 bytes --]

[-- Attachment #6: throw-char-desc-help-5.png --]
[-- Type: image/png, Size: 40430 bytes --]

[-- Attachment #7: throw-char-desc-help-1.png --]
[-- Type: image/png, Size: 38393 bytes --]

bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

>         character:
>                    c (99, #o143, #x63)

> Note the unnecessary newlines after `character:', `syntax:', and
> `category:'.  This is uncalled for.

I agree, the newline does nothing, because if a line is too long, adding
a newline and re-indenting still leaves it too long.

Fixed in trunk.