From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#10127: 24.0.91; wrong window width calc for `C-u C-x =' when *Help* in separate frame Date: Fri, 25 Nov 2011 10:06:52 +0200 Message-ID: <83wrao8w2r.fsf@gnu.org> References: <33462449944A4AD488077588779E681E@us.oracle.com> <83y5v58if1.fsf@gnu.org> <0797981120E94694A8751992E871E874@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1322208456 22706 80.91.229.12 (25 Nov 2011 08:07:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 25 Nov 2011 08:07:36 +0000 (UTC) Cc: 10127@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 25 09:07:32 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RTqol-0006xQ-OT for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Nov 2011 09:07:31 +0100 Original-Received: from localhost ([::1]:39527 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTqol-0005dI-8E for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Nov 2011 03:07:31 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:57041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTqoj-0005dD-64 for bug-gnu-emacs@gnu.org; Fri, 25 Nov 2011 03:07:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTqoh-00058T-RU for bug-gnu-emacs@gnu.org; Fri, 25 Nov 2011 03:07:29 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTqoh-00058J-K8 for bug-gnu-emacs@gnu.org; Fri, 25 Nov 2011 03:07:27 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RTqqE-0007Me-8D for bug-gnu-emacs@gnu.org; Fri, 25 Nov 2011 03:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Nov 2011 08:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10127 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10127-submit@debbugs.gnu.org id=B10127.132220851228266 (code B ref 10127); Fri, 25 Nov 2011 08:09:02 +0000 Original-Received: (at 10127) by debbugs.gnu.org; 25 Nov 2011 08:08:32 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RTqpk-0007Lq-62 for submit@debbugs.gnu.org; Fri, 25 Nov 2011 03:08:32 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RTqpg-0007Lg-E9 for 10127@debbugs.gnu.org; Fri, 25 Nov 2011 03:08:29 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LV700700IGCK200@a-mtaout20.012.net.il> for 10127@debbugs.gnu.org; Fri, 25 Nov 2011 10:06:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.228.50.247]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LV7006J5IJDWWD0@a-mtaout20.012.net.il>; Fri, 25 Nov 2011 10:06:51 +0200 (IST) In-reply-to: <0797981120E94694A8751992E871E874@us.oracle.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 25 Nov 2011 03:09:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:54295 Archived-At: > From: "Drew Adams" > 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.