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

["Drew Adams" <drew.adams@oracle.com>]

[-- 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 --]