From drew.adams@oracle.com Fri Mar 6 16:21:41 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Mar 2009 00:21:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,GENDER autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n270LcP7027630 for ; Fri, 6 Mar 2009 16:21:39 -0800 Received: from mail.gnu.org ([199.232.76.166]:45520 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LfkIL-0007sf-Hp for emacs-pretest-bug@gnu.org; Fri, 06 Mar 2009 19:21:37 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LfkIF-0007ba-7Q for emacs-pretest-bug@gnu.org; Fri, 06 Mar 2009 19:21:33 -0500 Received: from rcsinet11.oracle.com ([148.87.113.123]:20690 helo=rgminet11.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lfh1Y-0003XH-Hb for emacs-pretest-bug@gnu.org; Fri, 06 Mar 2009 15:52:04 -0500 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n26KsgOM029227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Mar 2009 20:54:44 GMT Received: from acsmt700.oracle.com (acsmt700.oracle.com [141.146.40.70]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n26KqBZQ026401 for ; Fri, 6 Mar 2009 20:52:12 GMT Received: from dradamslap1 (/141.144.64.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Mar 2009 20:51:57 +0000 From: "Drew Adams" To: Subject: 23.0.90; Man buffer improperly formatted - wrong width Date: Fri, 6 Mar 2009 12:51:59 -0800 Message-ID: <008301c99e9d$65578b60$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmenWR09rR5tre2QOCi5Nl0NQRpjA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt700.oracle.com [141.146.40.70] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020A.49B18CEE.0214:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) emacs -Q load library cygwin-mount.el, then setup-cygwin.el: http://www.emacswiki.org/emacs/cygwin-mount.el http://www.emacswiki.org/emacs/setup-cygwin.el Use /bin/bash.exe as SHELL. M-x set-variable RET pop-up-frames RET t Resize the current frame so that it is, say, only 30 chars wide. M-x man RET bash RET Buffer *Man bash* is shown in a new frame. The frame has the usual default width of 80 chars. But the text of the buffer is formatted to be only 30 chars wide. Clearly a mismatch and not what a user expects or intends. This same bug exists for Emacs 22 (e.g. 22.3) and Emacs 21 (e.g. 21.3.1). Emacs 20 (e.g. 20.7) has no such bug. In Emacs 21, the bug occurs even without loading the two Cywin helper libraries. With my SHELL var set to /bin/bash.exe, I cannot test Emacs 22 or 23 without loading those libraries, but I suspect the same bug occurs, as it does in Emacs 21. IOW, I don't think this has anything to do with using Cygwin. Please don't suggest customizing `Man-frame-parameters' or some such. This should just work, normally, with no need for any user tweaking. Setting `pop-up-frames' to non-nil does not imply that you want the Man output (in a normal-width frame) to have the same width as the frame that was current when you called `man'. In GNU Emacs 23.0.90.1 (i386-mingw-nt5.1.2600) of 2009-02-01 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4)' From cyd@stupidchicken.com Fri Mar 6 20:21:01 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 7 Mar 2009 04:21:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=GENDER autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n274KxYL025988 for <2588@emacsbugs.donarmstrong.com>; Fri, 6 Mar 2009 20:21:00 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id 657BB57E1D7; Fri, 6 Mar 2009 23:22:09 -0500 (EST) From: Chong Yidong To: "Drew Adams" Cc: 2588@debbugs.gnu.org Subject: Re: 23.0.90; Man buffer improperly formatted - wrong width Date: Fri, 06 Mar 2009 23:22:09 -0500 Message-ID: <873adqnery.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > M-x set-variable RET pop-up-frames RET t > > Resize the current frame so that it is, say, only 30 chars wide. > > M-x man RET bash RET > > Buffer *Man bash* is shown in a new frame. The frame has the usual > default width of 80 chars. But the text of the buffer is formatted to > be only 30 chars wide. Doing what you want is not a trivial to man.el, I think. You can change the `Man-width' options if you want to fix the width. From drew.adams@oracle.com Fri Mar 6 20:50:22 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 7 Mar 2009 04:50:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,GENDER autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n274oJfx001202 for <2588@emacsbugs.donarmstrong.com>; Fri, 6 Mar 2009 20:50:20 -0800 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n274nwQr021674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Mar 2009 04:49:59 GMT Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n274oOC0008323; Sat, 7 Mar 2009 04:50:25 GMT Received: from dradamslap1 (/24.5.128.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 Mar 2009 04:50:10 +0000 From: "Drew Adams" To: "'Chong Yidong'" Cc: <2588@debbugs.gnu.org> References: <873adqnery.fsf@cyd.mit.edu> Subject: RE: 23.0.90; Man buffer improperly formatted - wrong width Date: Fri, 6 Mar 2009 20:50:14 -0800 Message-ID: <001001c99ee0$35257540$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <873adqnery.fsf@cyd.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acme3FVtCiLPd9NeRLePOft8MfwtCwAALfgg X-Source-IP: acsmt707.oracle.com [141.146.40.85] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020A.49B1FD03.0257:SCFSTAT928724,ss=1,fgs=0 > > M-x set-variable RET pop-up-frames RET t > > > > Resize the current frame so that it is, say, only 30 chars wide. > > > > M-x man RET bash RET > > > > Buffer *Man bash* is shown in a new frame. The frame has the usual > > default width of 80 chars. But the text of the buffer is > > formatted to be only 30 chars wide. > > Doing what you want is not a trivial to man.el, I think. You > can change the `Man-width' options if you want to fix the width. What do you mean "doing what I want"? This is not an enhancement request for something "I want". This is a bug report. There's no way this can be defended as reasonable or expected behavior. Imagine if `man' did something like that also for users who have `pop-up-frames' = nil. You would have heard about it on day 1. Would you tell them to go and customize the `Man-width' options to "fix the width" and get sane behavior? Preposterous. Fewer users use non-nil `pop-up-frames', but that's no reason that Emacs shouldn't work reasonably with a non-nil value. If the fix is non-trivial, as you say, it would be because the code for `man' never should have been tightly tailored for only the nil case - too "clever" by half. Why is there any relation (code coupling) between the calling frame and the resulting `man' display? Why should the width (or other parameters) of the calling frame affect the buffer text width of the man display - and in another frame, to boot. Makes no sense. Do we do that for *Help* or *info* or NEWS or Dired or any other buffer display? Of course not. Sure, man pages are formatted, and they need to use some set width, but obviously the current code is able to handle different widths for formatting. All that's needed is to stop getting the width value to use from the calling frame. Just look at it, to see how silly it is. I'm surprised that you would try to defend keeping such outlandish behavior with such a lame argument. From eliz@gnu.org Sat Mar 7 05:58:36 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 7 Mar 2009 13:58:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout7.012.net.il (mtaout7.012.net.il [84.95.2.19]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n27DwWQw018529 for <2588@emacsbugs.donarmstrong.com>; Sat, 7 Mar 2009 05:58:33 -0800 Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KG5003002TC8X00@i-mtaout7.012.net.il> for 2588@emacsbugs.donarmstrong.com; Sat, 07 Mar 2009 15:58:27 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KG5000TZ2TFPH00@i-mtaout7.012.net.il>; Sat, 07 Mar 2009 15:58:27 +0200 (IST) Date: Sat, 07 Mar 2009 15:58:22 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: <008301c99e9d$65578b60$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams , 2588@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: References: <008301c99e9d$65578b60$0200a8c0@us.oracle.com> > From: "Drew Adams" > Date: Fri, 6 Mar 2009 12:51:59 -0800 > Cc: > > M-x set-variable RET pop-up-frames RET t > > Resize the current frame so that it is, say, only 30 chars wide. > > M-x man RET bash RET > > Buffer *Man bash* is shown in a new frame. The frame has the usual > default width of 80 chars. But the text of the buffer is formatted to > be only 30 chars wide. I cannot reproduce this on my system, but I think I know why, see below. > This same bug exists for Emacs 22 (e.g. 22.3) and Emacs 21 > (e.g. 21.3.1). Emacs 20 (e.g. 20.7) has no such bug. That's because Emacs 20 didn't set COLUMNS in the environment before invoking the `man' program. But that had other adverse effects on X, see the comments in man.el where it sets COLUMNS. > In Emacs 21, the bug occurs even without loading the two Cywin helper > libraries. With my SHELL var set to /bin/bash.exe, I cannot test > Emacs 22 or 23 without loading those libraries, but I suspect the same > bug occurs, as it does in Emacs 21. IOW, I don't think this has > anything to do with using Cygwin. Actually, it does have something to do with Cygwin: I'm guessing your man.exe comes from Cygwin, and tries to honor the COLUMNS environment variable. My man.exe is a natively compiled clone of the Unix `man' command, and it doesn't pay attention to COLUMNS, so it always produces text whose width assumes an 80-column display, no matter what COLUMNS says. From eliz@gnu.org Sat Mar 7 06:16:04 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 7 Mar 2009 14:16:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout2.012.net.il (mtaout2.012.net.il [84.95.2.4]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n27EG0NF024319 for <2588@emacsbugs.donarmstrong.com>; Sat, 7 Mar 2009 06:16:01 -0800 Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KG500B003KEQ200@i_mtaout2.012.net.il> for 2588@emacsbugs.donarmstrong.com; Sat, 07 Mar 2009 16:16:36 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KG500G8S3NKGNW0@i_mtaout2.012.net.il>; Sat, 07 Mar 2009 16:16:33 +0200 (IST) Date: Sat, 07 Mar 2009 16:15:54 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: <001001c99ee0$35257540$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams , 2588@debbugs.gnu.org Cc: cyd@stupidchicken.com Reply-to: Eli Zaretskii Message-id: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> > From: "Drew Adams" > Date: Fri, 6 Mar 2009 20:50:14 -0800 > Cc: 2588@emacsbugs.donarmstrong.com > > > Doing what you want is not a trivial to man.el, I think. You > > can change the `Man-width' options if you want to fix the width. > > What do you mean "doing what I want"? This is not an enhancement request for > something "I want". This is a bug report. There's no way this can be defended as > reasonable or expected behavior. > > Imagine if `man' did something like that also for users who have `pop-up-frames' > = nil. You would have heard about it on day 1. Would you tell them to go and > customize the `Man-width' options to "fix the width" and get sane behavior? > Preposterous. As usual, Drew, you need to calm down. No one is jumping you, so please don't jump others in response. What Yidong was trying to say is this: Emacs sets the environment variable COLUMNS depending on the value of Man-width. Setting that variable to an integer value is supposed to cause `man' to format man pages to that width. Any other value causes the man pages to be formatted according to the width of the current window or the currently selected frame (depending on whether the variable is nil or t). The problem is, AFAICS, that with pop-up-frames `man' is run _before_ the frame to display its output is created. To do what you want we need to know in advance what would be the width of that frame. Do you have any suggestions for how to pull that trick? Pop-up frames could have non-default user-defined frame parameters for them, right? One thing we could easily do is not set COLUMNS in the environment if pop-up-frames is being used, but then you'd probably come up with another use-case, where pop-up frames are configured to come up with a width that is different from the default, and tell that this is a bug... However, as this at least restores the pre-v21 behavior, it could be the best solution for Emacs 23.1. Last, but not least, I recommend using WoMan on Windows in preference to `man'. Since it's written in Lisp, it interacts better with Emacs features, as far as text formatting is concerned. In particular, if you set woman-fill-frame to t, you will get what you want, I think. > Just look at it, to see how silly it is. I'm surprised that you would try to > defend keeping such outlandish behavior with such a lame argument. No one is defending this behavior. You just have been told that fixing it is not easy, which is a far cry. From drew.adams@oracle.com Sat Mar 7 08:20:11 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 7 Mar 2009 16:20:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n27GK7PO024824 for <2588@emacsbugs.donarmstrong.com>; Sat, 7 Mar 2009 08:20:08 -0800 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n27GJt2q007478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Mar 2009 16:19:56 GMT Received: from acsmt705.oracle.com (acsmt705.oracle.com [141.146.40.83]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n27GK0rt000432; Sat, 7 Mar 2009 16:20:01 GMT Received: from dradamslap1 (/141.144.80.165) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 Mar 2009 08:19:56 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" , <2588@debbugs.gnu.org> References: <008301c99e9d$65578b60$0200a8c0@us.oracle.com> Subject: RE: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Date: Sat, 7 Mar 2009 08:20:01 -0800 Message-ID: <000501c99f40$91ac95e0$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmfLQOhb4aQJWiwSGan401rVxNYLQACtgBg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt705.oracle.com [141.146.40.83] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.49B29EAE.01DF:SCFSTAT928724,ss=1,fgs=0 > From: Eli Zaretskii Sent: Saturday, March 07, 2009 5:58 AM > > M-x set-variable RET pop-up-frames RET t > > > > Resize the current frame so that it is, say, only 30 chars wide. > > > > M-x man RET bash RET > > > > Buffer *Man bash* is shown in a new frame. The frame has the usual > > default width of 80 chars. But the text of the buffer is > > formatted to be only 30 chars wide. > > I cannot reproduce this on my system, but I think I know why, see > below. > > > This same bug exists for Emacs 22 (e.g. 22.3) and Emacs 21 > > (e.g. 21.3.1). Emacs 20 (e.g. 20.7) has no such bug. > > That's because Emacs 20 didn't set COLUMNS in the environment before > invoking the `man' program. But that had other adverse effects on X, > see the comments in man.el where it sets COLUMNS. > > > In Emacs 21, the bug occurs even without loading the two > > Cywin helper libraries. With my SHELL var set to /bin/bash.exe, > > I cannot test Emacs 22 or 23 without loading those libraries, > > but I suspect the same bug occurs, as it does in Emacs 21. IOW, > > I don't think this has anything to do with using Cygwin. > > Actually, it does have something to do with Cygwin: I'm guessing your > man.exe comes from Cygwin, and tries to honor the COLUMNS environment > variable. My man.exe is a natively compiled clone of the Unix `man' > command, and it doesn't pay attention to COLUMNS, so it always > produces text whose width assumes an 80-column display, no matter what > COLUMNS says. That makes sense. That Emacs sets COLUMNS to `Man-width' is fine. The problem is apparently that If `Man-width' is not defined (as a positive integer) then Emacs sets COLUMNS to the current `frame-width'. That's the cause of the bug, AFAICT. Logically, the current (soon to be previous) frame width is 100% irrelevant to `man's display. From drew.adams@oracle.com Sat Mar 7 08:20:42 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 7 Mar 2009 16:20:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=FOURLA,GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n27GKdeQ025974 for <2588@emacsbugs.donarmstrong.com>; Sat, 7 Mar 2009 08:20:40 -0800 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n27GL9Mj024895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Mar 2009 16:21:10 GMT Received: from acsmt703.oracle.com (acsmt703.oracle.com [141.146.40.81]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n27GKW5A001045; Sat, 7 Mar 2009 16:20:33 GMT Received: from dradamslap1 (/141.144.80.165) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 Mar 2009 08:20:28 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" , <2588@debbugs.gnu.org> Cc: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> Subject: RE: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Date: Sat, 7 Mar 2009 08:20:33 -0800 Message-ID: <000601c99f40$a47c9080$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmfL1G3YlisWYNcQmamNYKS/e1fwgACL7pw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt703.oracle.com [141.146.40.81] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.49B29ECE.0093:SCFSTAT928724,ss=1,fgs=0 > From: Eli Zaretskii Sent: Saturday, March 07, 2009 6:16 AM > Emacs sets the environment > variable COLUMNS depending on the value of Man-width. Setting that > variable to an integer value is supposed to cause `man' to format man > pages to that width. Any other value causes the man pages to be > formatted according to the width of the current window or the > currently selected frame (depending on whether the variable is nil or > t). > > The problem is, AFAICS, that with pop-up-frames `man' is run _before_ > the frame to display its output is created. That's just what I was saying. It makes no sense to measure the previous frame's width and use that. That's clearly a recipe for trouble. > To do what you want we > need to know in advance what would be the width of that frame. Do you > have any suggestions for how to pull that trick? Pop-up frames could > have non-default user-defined frame parameters for them, right? This should be handled the same way it and similar things are handled elsewhere in Emacs: If the formatting cannot be made to fit the new window or frame, because the new window or frame size (or other parameters) is not known at the time the `man' process is started, then just use a fixed default width - e.g. 80 chars. And even if the new window or frame size can be known ahead of time, it's not necessarily a good idea to base the `man' display on that. It depends on user intention: does the user typically want fixed-size windows and frames, and expect buffers displayed in those to fit their sizes, or does the user typically let windows and frames fit the buffer display (or just ignore it). Different users have different preferences. Generally, it makes more sense for a new window or frame to not impose its parameters on its displayed buffer. If any fitting is to be done, it is generally the window or frame that should accommodate the buffer, perhaps resizing itself, not vice versa. Where else in Emacs do we format the buffer ahead of time to fit the window or frame that it will be displayed in? If there are any such contexts, in how many of them do we try to do that even when the window or frame parameters are *not known* ahead of time? The typical approach for formatted buffers in Emacs is to format the text (e.g. for *Help* or *Apropos*) independently of any knowledge of the window or frame in which it will be displayed. It would be a mistake for the Emacs `man' code to try to figure out (e.g. by examining special-frame regexp and alist, default frame alist,...) what the new frame parameters might be - or even whether a new pop-up frame will be used. The proper behavior is to simply use a default text width, when nothing better is known. Either (1) something buffer-specific, like `Man-width' or `fill-column', if known - specific for the `Man' buffer, that is, not for the previous buffer, or (2) just a constant, like 80. This is about formatting the `Man' buffer's text, so variables that apply to the `Man' buffer's text can be pertinent. Variables that apply only to the previous buffer or its window or frame should not be used as guides for `Man'. > One thing we could easily do is not set COLUMNS in the environment if > pop-up-frames is being used, Yes, please do that. Please do not set COLUMNS to the current `frame-width'. > but then you'd probably come up with > another use-case, where pop-up frames are configured to come up with a > width that is different from the default, and tell that this is a > bug... However, as this at least restores the pre-v21 behavior, it > could be the best solution for Emacs 23.1. No, it would not be a bug in that case, even if it might be behavior that we could still try to improve in some way. *If* you could handle something like non-nil `pop-up-frames' cleverly and properly in all cases, that would be OK. If not however, the default, fall-back behavior should at least be something reasonable, something that users might expect. There is no logical relation between the `Man' buffer formatting and the previous frame width, so that approach is not reasonable. (DWIM should be only icing on an otherwise solid and stable cake. There needs to be a cake under the icing.) > Last, but not least, I recommend using WoMan on Windows in preference > to `man'. Since it's written in Lisp, it interacts better with Emacs > features, as far as text formatting is concerned. In particular, if > you set woman-fill-frame to t, you will get what you want, I think. Thanks for the info; I will keep it in mind. But it's of course irrelevant to this bug report. This is not about finding a solution for me: customizing `Man-width", or using Woman as a substitute, or whatever. I didn't report this bug for myself; I reported it for Emacs. I don't use `man' that often anymore, myself. I discovered this problem only yesterday. I invoked `man' from a Dired buffer with Dired details hidden (and the frame fit to the buffer), so the frame was narrow. From eliz@gnu.org Sat Mar 7 11:28:01 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 7 Mar 2009 19:28:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout6.012.net.il (mtaout6.012.net.il [84.95.2.16]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n27JRvmB011122 for <2588@emacsbugs.donarmstrong.com>; Sat, 7 Mar 2009 11:27:59 -0800 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KG500900HI82700@i-mtaout6.012.net.il> for 2588@emacsbugs.donarmstrong.com; Sat, 07 Mar 2009 21:28:34 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KG500790I3I3730@i-mtaout6.012.net.il>; Sat, 07 Mar 2009 21:28:31 +0200 (IST) Date: Sat, 07 Mar 2009 21:27:52 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: <000601c99f40$a47c9080$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Cc: 2588@debbugs.gnu.org, cyd@stupidchicken.com Reply-to: Eli Zaretskii Message-id: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> > From: "Drew Adams" > Cc: > Date: Sat, 7 Mar 2009 08:20:33 -0800 > > > One thing we could easily do is not set COLUMNS in the environment if > > pop-up-frames is being used, > > Yes, please do that. Please do not set COLUMNS to the current `frame-width'. Yidong, is this solution fine with you? From cyd@stupidchicken.com Sat Mar 7 11:42:42 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 7 Mar 2009 19:42:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n27Jgd1A014954 for <2588@emacsbugs.donarmstrong.com>; Sat, 7 Mar 2009 11:42:40 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id 5EA0757E232; Sat, 7 Mar 2009 14:43:50 -0500 (EST) From: Chong Yidong To: Eli Zaretskii Cc: Drew Adams , 2588@debbugs.gnu.org Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> Date: Sat, 07 Mar 2009 14:43:50 -0500 In-Reply-To: (Eli Zaretskii's message of "Sat, 07 Mar 2009 21:27:52 +0200") Message-ID: <873adpazk9.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Eli Zaretskii writes: >> > One thing we could easily do is not set COLUMNS in the environment if >> > pop-up-frames is being used, >> >> Yes, please do that. Please do not set COLUMNS to the current `frame-width'. > > Yidong, is this solution fine with you? The width of a pop-up frame has, in general, nothing to do with the default value of COLUMNS (or the default value that the formatter assumes if COLUMNS is omitted). So I don't see how this is any improvement. From drew.adams@oracle.com Sat Mar 7 11:45:52 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 7 Mar 2009 19:45:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n27Jjnod016188 for <2588@emacsbugs.donarmstrong.com>; Sat, 7 Mar 2009 11:45:50 -0800 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n27JmP1c017974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Mar 2009 19:48:27 GMT Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n27JjrgH024447; Sat, 7 Mar 2009 19:45:55 GMT Received: from dradamslap1 (/141.144.72.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 Mar 2009 11:45:39 -0800 From: "Drew Adams" To: "'Chong Yidong'" , "'Eli Zaretskii'" Cc: <2588@debbugs.gnu.org> References: <873adqnery.fsf@cyd.mit.edu><001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> Subject: RE: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Date: Sat, 7 Mar 2009 11:45:36 -0800 Message-ID: <000601c99f5d$49aefef0$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <873adpazk9.fsf@cyd.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmfXQypWG9aplvgTM6qbDt36IcbCAAABTew X-Source-IP: acsmt704.oracle.com [141.146.40.82] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.49B2CEE4.0228:SCFSTAT928724,ss=1,fgs=0 > >> > One thing we could easily do is not set COLUMNS in the > >> > environment if pop-up-frames is being used, > >> > >> Yes, please do that. Please do not set COLUMNS to the > >> current `frame-width'. > > > > Yidong, is this solution fine with you? > > The width of a pop-up frame has, in general, nothing to do with the > default value of COLUMNS (or the default value that the formatter > assumes if COLUMNS is omitted). So I don't see how this is any > improvement. That's why I said "please do *NOT* set COLUMNS to the current frame's width. The problem is that it is currently being set that way; it should not be. From eliz@gnu.org Sat Mar 7 12:08:14 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 7 Mar 2009 20:08:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout1.012.net.il (mtaout1.012.net.il [84.95.2.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n27K8AAO022307 for <2588@emacsbugs.donarmstrong.com>; Sat, 7 Mar 2009 12:08:11 -0800 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KG500800J1CL900@i-mtaout1.012.net.il> for 2588@emacsbugs.donarmstrong.com; Sat, 07 Mar 2009 22:08:27 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KG5008JLJXYQOF0@i-mtaout1.012.net.il>; Sat, 07 Mar 2009 22:08:23 +0200 (IST) Date: Sat, 07 Mar 2009 22:07:44 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: <873adpazk9.fsf@cyd.mit.edu> X-012-Sender: halo1@inter.net.il To: Chong Yidong Cc: drew.adams@oracle.com, 2588@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> > From: Chong Yidong > Cc: Drew Adams , 2588@emacsbugs.donarmstrong.com > Date: Sat, 07 Mar 2009 14:43:50 -0500 > > Eli Zaretskii writes: > > >> > One thing we could easily do is not set COLUMNS in the environment if > >> > pop-up-frames is being used, > >> > >> Yes, please do that. Please do not set COLUMNS to the current `frame-width'. > > > > Yidong, is this solution fine with you? > > The width of a pop-up frame has, in general, nothing to do with the > default value of COLUMNS (or the default value that the formatter > assumes if COLUMNS is omitted). So I don't see how this is any > improvement. It is an "improvement" in the sense that, when pop-up-frames is non-nil, Emacs 23 will behave like Emacs 20 did. AFAICS, we started setting COLUMNS in the environment because on some GNU/Linux system, under X, not setting it would result in over-long lines. To avoid that with pop-up-frames, we could set COLUMNS to the value 80. For a frame that is not yet created, 80 sounds like a better default than the width of some other frame/window. From monnier@iro.umontreal.ca Sat Mar 7 20:05:18 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 04:05:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.5 required=4.0 tests=GENDER,HAS_BUG_NUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n2845E0e019614 for <2588@emacsbugs.donarmstrong.com>; Sat, 7 Mar 2009 20:05:16 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EADLTsklLd/DG/2dsb2JhbACBTtFJhAUGhCI X-IronPort-AV: E=Sophos;i="4.38,321,1233550800"; d="scan'208";a="34847724" Received: from 75-119-240-198.dsl.teksavvy.com (HELO pastel.home) ([75.119.240.198]) by ironport2-out.teksavvy.com with ESMTP; 07 Mar 2009 23:05:09 -0500 Received: by pastel.home (Postfix, from userid 20848) id B8EAD7FA2; Sat, 7 Mar 2009 23:05:08 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Cc: 2588@debbugs.gnu.org, Drew Adams , cyd@stupidchicken.com Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Message-ID: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> Date: Sat, 07 Mar 2009 23:05:08 -0500 In-Reply-To: (Eli Zaretskii's message of "Sat, 07 Mar 2009 16:15:54 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > The problem is, AFAICS, that with pop-up-frames `man' is run _before_ > the frame to display its output is created. To do what you want we We could try to fix this: I think it would actually be desirable to pop up the frame immediately and then asynchronously fill it as man's output comes in. This said, we could also just remove the COLUMNS business. Who introduced this COLUMNS thingy and what was the motivation for it? Stefan From cyd@stupidchicken.com Sun Mar 8 08:44:42 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 15:44:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28Fidu5008361 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 08:44:40 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 2ADB657E205; Sun, 8 Mar 2009 11:45:51 -0400 (EDT) From: Chong Yidong To: Stefan Monnier Cc: Eli Zaretskii , 2588@debbugs.gnu.org, Drew Adams Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> Date: Sun, 08 Mar 2009 11:45:51 -0400 In-Reply-To: (Stefan Monnier's message of "Sat, 07 Mar 2009 23:05:08 -0500") Message-ID: <871vt86ms0.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Stefan Monnier writes: > We could try to fix this: I think it would actually be desirable to pop > up the frame immediately and then asynchronously fill it as man's output > comes in. > > This said, we could also just remove the COLUMNS business. > Who introduced this COLUMNS thingy and what was the motivation for it? This is explained in the code comments: it's required to ensure that the output of the manpage formatter has the same number of columns as the Emacs window/frame. From drew.adams@oracle.com Sun Mar 8 08:57:27 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 15:57:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28FvOMM012093 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 08:57:25 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n28FvCqw019642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Mar 2009 15:57:13 GMT Received: from acsmt705.oracle.com (acsmt705.oracle.com [141.146.40.83]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n28FvHvt023959; Sun, 8 Mar 2009 15:57:19 GMT Received: from dradamslap1 (/141.144.168.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Mar 2009 08:57:13 -0700 From: "Drew Adams" To: "'Chong Yidong'" , "'Stefan Monnier'" Cc: "'Eli Zaretskii'" , <2588@debbugs.gnu.org> References: <873adqnery.fsf@cyd.mit.edu><001001c99ee0$35257540$0200a8c0@us.oracle.com> <871vt86ms0.fsf@cyd.mit.edu> Subject: RE: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Date: Sun, 8 Mar 2009 08:57:10 -0700 Message-ID: <000001c9a006$8ac230c0$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <871vt86ms0.fsf@cyd.mit.edu> Thread-Index: AcmgBPlSFaPBCzqkTT2kvjw73AhZAQAAEIQg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt705.oracle.com [141.146.40.83] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0206.49B3EADB.01E0:SCFSTAT928724,ss=1,fgs=0 > > We could try to fix this: I think it would actually be > > desirable to pop up the frame immediately and then > > asynchronously fill it as man's output comes in. > > > > This said, we could also just remove the COLUMNS business. > > Who introduced this COLUMNS thingy and what was the > > motivation for it? > > This is explained in the code comments: it's required to > ensure that the output of the manpage formatter has the > same number of columns as the Emacs window/frame. (1) The code does not do that correctly in the case cited: The new frame is 80 columns wide, but the text is formatted to 30 columns wide. (2) The code cannot always know the number of columns of the to-be-created frame. (3) That number of columns, even when the code can know it accurately, is *not pertinent* to how the buffer should be formatted. The code should not assume fixed window or frame sizes, or that those sizes should govern formatting of the buffer text. That is not what is done generally in Emacs when text is formatted (e.g. *Help*, *Apropos*,...). The code here is nonstandard - Emacs generally does not behave like this. Some particular group of users might (*might* - not sure) find this code helpful, but for other users it is downright harmful. Please revert this unhelpful cleverness. From cyd@stupidchicken.com Sun Mar 8 09:07:40 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 16:07:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28G7bSt015434 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 09:07:39 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 9E1C857E205; Sun, 8 Mar 2009 12:08:49 -0400 (EDT) From: Chong Yidong To: Eli Zaretskii Cc: drew.adams@oracle.com, 2588@debbugs.gnu.org Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> Date: Sun, 08 Mar 2009 12:08:49 -0400 In-Reply-To: (Eli Zaretskii's message of "Sat, 07 Mar 2009 22:07:44 +0200") Message-ID: <87wsb0m1ym.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Eli Zaretskii writes: > AFAICS, we started setting COLUMNS in the environment because on some > GNU/Linux system, under X, not setting it would result in over-long > lines. To avoid that with pop-up-frames, we could set COLUMNS to the > value 80. For a frame that is not yet created, 80 sounds like a > better default than the width of some other frame/window. Right, and this handles the case where the selected frame is abnormally wide. But suppose the selected frame is the normal width, and has a width of 200. The default-to-80-columns would do the wrong thing. I think we could use default-frame-alist to guess the number of columns. From drew.adams@oracle.com Sun Mar 8 09:23:47 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 16:23:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28GNjVm019295 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 09:23:46 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n28GOm4p008966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Mar 2009 16:24:49 GMT Received: from acsmt702.oracle.com (acsmt702.oracle.com [141.146.40.80]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n28GNc91019695; Sun, 8 Mar 2009 16:23:40 GMT Received: from dradamslap1 (/141.144.168.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Mar 2009 09:23:34 -0700 From: "Drew Adams" To: "'Chong Yidong'" , "'Eli Zaretskii'" Cc: <2588@debbugs.gnu.org> References: <873adqnery.fsf@cyd.mit.edu><001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> Subject: RE: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Date: Sun, 8 Mar 2009 09:23:31 -0700 Message-ID: <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87wsb0m1ym.fsf@cyd.mit.edu> Thread-Index: AcmgCBwyJ/8UkXEBSDenVzegi4yx8AAABfGw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt702.oracle.com [141.146.40.80] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010201.49B3F108.012B:SCFSTAT928724,ss=1,fgs=0 > > AFAICS, we started setting COLUMNS in the environment > > because on some GNU/Linux system, under X, not setting > > it would result in over-long lines. To avoid that with > > pop-up-frames, we could set COLUMNS to the > > value 80. For a frame that is not yet created, 80 sounds like a > > better default than the width of some other frame/window. > > Right, and this handles the case where the selected frame is > abnormally wide. But suppose the selected frame is the normal > width, and has a width of 200. The default-to-80-columns > would do the wrong thing. > > I think we could use default-frame-alist to guess the number > of columns. No, no, no. What is the wrong thing is to guess the number of text columns based on *any* window or frame value - either from an existing window or frame, or from a default alist. As you yourself stated correctly (perhaps without meaning to): "The width of a pop-up frame has, in general, nothing to do with the default value of COLUMNS". Please do not set COLUMNS to any value that is designed for frames - that includes `default-frame-alist'. COLUMNS is about buffer text formatting, not about frame sizing. The formatting width for the `Man' buffer, like that of for the *Help* buffer or the *Apropos* buffer or others, should have *nothing to do* with the width of any window or frame parameter - existing or default. Use either: (1) a user preference designed specifically for formatting the `Man' buffer text (e.g. `Man-width') or, barring that, (2) a user preference designed for formatting buffer text generally (e.g. `fill-column') or, barring that, (3) a hard-coded value (e.g. 80) intended for buffer text formatting (not for window or frame sizing). Please do not use any value designed for windows or frames. They are irrelevant and can only be a nuisance here. From cyd@stupidchicken.com Sun Mar 8 12:04:53 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 19:04:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28J4oUl028881 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 12:04:52 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id D799057E205; Sun, 8 Mar 2009 15:06:02 -0400 (EDT) From: Chong Yidong To: "Drew Adams" Cc: "'Eli Zaretskii'" , <2588@debbugs.gnu.org> Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> Date: Sun, 08 Mar 2009 15:06:02 -0400 In-Reply-To: <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> (Drew Adams's message of "Sun, 8 Mar 2009 09:23:31 -0700") Message-ID: <87y6vfomw5.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Drew Adams" writes: > Please do not set COLUMNS to any value that is designed for frames - > that includes `default-frame-alist'. COLUMNS is about buffer text > formatting, not about frame sizing. > > The formatting width for the `Man' buffer, like that of for the *Help* > buffer or the *Apropos* buffer or others, should have *nothing to do* > with the width of any window or frame parameter - existing or default. The `man' facility is different from apropos or help---the text is generated by an external formatter, not by Emacs. If COLUMNS is omitted, the formatter output is too long for the frame width, on at least one (Debian) system. Setting COLUMNS to the frame width does the right thing most of the time, and covers more cases than a hardcoded value. It's true that it can fail for the pop-up-frames case, and we can work around that by using default-frame-alist. Certainly, it's always possible to come up with a special setup that makes this heuristic fail. But if you're setup is so special, just set Man-width and be done with it. From eliz@gnu.org Sun Mar 8 12:05:06 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 19:05:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout2.012.net.il (mtaout2.012.net.il [84.95.2.4]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28J50Lx028889 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 12:05:02 -0700 Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KG700G00BNUBQ00@i_mtaout2.012.net.il> for 2588@emacsbugs.donarmstrong.com; Sun, 08 Mar 2009 21:05:37 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KG70062JBP9QFO0@i_mtaout2.012.net.il>; Sun, 08 Mar 2009 21:05:34 +0200 (IST) Date: Sun, 08 Mar 2009 21:04:55 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: <87wsb0m1ym.fsf@cyd.mit.edu> X-012-Sender: halo1@inter.net.il To: Chong Yidong Cc: drew.adams@oracle.com, 2588@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> > From: Chong Yidong > Cc: drew.adams@oracle.com, 2588@emacsbugs.donarmstrong.com > Date: Sun, 08 Mar 2009 12:08:49 -0400 > > Eli Zaretskii writes: > > > AFAICS, we started setting COLUMNS in the environment because on some > > GNU/Linux system, under X, not setting it would result in over-long > > lines. To avoid that with pop-up-frames, we could set COLUMNS to the > > value 80. For a frame that is not yet created, 80 sounds like a > > better default than the width of some other frame/window. > > Right, and this handles the case where the selected frame is abnormally > wide. But suppose the selected frame is the normal width, and has a > width of 200. The default-to-80-columns would do the wrong thing. Again, I was talking _only_ about the use-case where pop-up-frames is non-nil. In that case, how do you know that default-to-80-columns is the wrong thing? The fact that the frame selected when "M-x man" is invoked is 200 columns wide says nothing about the frame that will be used to display the formatted manual. Or maybe you meant that the frame to be popped up will be 200 columns wide. But that is a marginal case, IMO, and it didn't work in Emacs 20, either. So we could leave that for fixing after the release, if ever. When pop-up-frames is nil, the current code works well, and we don't need to change it, IMO, certainly not before 23.1 is released. From eliz@gnu.org Sun Mar 8 12:24:01 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 19:24:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout2.012.net.il (mtaout2.012.net.il [84.95.2.4]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28JNvAW002175 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 12:23:59 -0700 Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KG700G00BNUBQ00@i_mtaout2.012.net.il> for 2588@emacsbugs.donarmstrong.com; Sun, 08 Mar 2009 21:24:35 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KG7009GLCKQIKO0@i_mtaout2.012.net.il>; Sun, 08 Mar 2009 21:24:28 +0200 (IST) Date: Sun, 08 Mar 2009 21:23:49 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: <87y6vfomw5.fsf@cyd.mit.edu> X-012-Sender: halo1@inter.net.il To: Chong Yidong Cc: drew.adams@oracle.com, 2588@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> > From: Chong Yidong > Cc: "'Eli Zaretskii'" , <2588@emacsbugs.donarmstrong.com> > Date: Sun, 08 Mar 2009 15:06:02 -0400 > > Setting COLUMNS to the frame width does the right thing most of the > time, and covers more cases than a hardcoded value. It's true that it > can fail for the pop-up-frames case, and we can work around that by > using default-frame-alist. ^^^^^^^^^^^^^^^^^^^ Shouldn't this be pop-up-frame-alist instead? Anyway, I wouldn't go for such adventures before Emacs 23.1 is released. Until then, I'd simply not set COLUMNS when pop-up-frames is non-nil. From cyd@stupidchicken.com Sun Mar 8 12:39:08 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 19:39:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28Jd6qv006017 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 12:39:07 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 26BEE57E205; Sun, 8 Mar 2009 15:40:18 -0400 (EDT) From: Chong Yidong To: Eli Zaretskii Cc: drew.adams@oracle.com, 2588@debbugs.gnu.org Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> Date: Sun, 08 Mar 2009 15:40:18 -0400 In-Reply-To: (Eli Zaretskii's message of "Sun, 08 Mar 2009 21:23:49 +0200") Message-ID: <87ljrfolb1.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Eli Zaretskii writes: > Anyway, I wouldn't go for such adventures before Emacs 23.1 is > released. Until then, I'd simply not set COLUMNS when pop-up-frames > is non-nil. I'm not sure we should make *any* change to this before the release. From monnier@iro.umontreal.ca Sun Mar 8 12:43:47 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 19:43:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.5 required=4.0 tests=GENDER,HAS_BUG_NUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28JhhuK007337 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 12:43:44 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EADm8s0lLd/DG/2dsb2JhbACBTtEOhAUGhCE X-IronPort-AV: E=Sophos;i="4.38,325,1233550800"; d="scan'208";a="34865095" Received: from 75-119-240-198.dsl.teksavvy.com (HELO ceviche.home) ([75.119.240.198]) by ironport2-out.teksavvy.com with ESMTP; 08 Mar 2009 15:43:37 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 956EEB403E; Sun, 8 Mar 2009 15:43:39 -0400 (EDT) From: Stefan Monnier To: Chong Yidong Cc: Eli Zaretskii , 2588@debbugs.gnu.org, Drew Adams Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Message-ID: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <871vt86ms0.fsf@cyd.mit.edu> Date: Sun, 08 Mar 2009 15:43:39 -0400 In-Reply-To: <871vt86ms0.fsf@cyd.mit.edu> (Chong Yidong's message of "Sun, 08 Mar 2009 11:45:51 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> We could try to fix this: I think it would actually be desirable to pop >> up the frame immediately and then asynchronously fill it as man's output >> comes in. >> >> This said, we could also just remove the COLUMNS business. >> Who introduced this COLUMNS thingy and what was the motivation for it? > This is explained in the code comments: it's required to ensure that the > output of the manpage formatter has the same number of columns as the > Emacs window/frame. Well, that part I understood, even without the comment ;-) The question is: what was the motivation to adjust the number of columns to that of the Emacs window/frame? Stefan From monnier@iro.umontreal.ca Sun Mar 8 12:45:52 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 19:45:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.5 required=4.0 tests=GENDER,HAS_BUG_NUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28Jjn3F008569 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 12:45:50 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJO9s0lLd/DG/2dsb2JhbACBTtEQhAUGhCE X-IronPort-AV: E=Sophos;i="4.38,325,1233550800"; d="scan'208";a="34865140" Received: from 75-119-240-198.dsl.teksavvy.com (HELO ceviche.home) ([75.119.240.198]) by ironport2-out.teksavvy.com with ESMTP; 08 Mar 2009 15:45:44 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 45A5AB403E; Sun, 8 Mar 2009 15:45:46 -0400 (EDT) From: Stefan Monnier To: Chong Yidong Cc: 2588@debbugs.gnu.org, Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Message-ID: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> Date: Sun, 08 Mar 2009 15:45:46 -0400 In-Reply-To: <87wsb0m1ym.fsf@cyd.mit.edu> (Chong Yidong's message of "Sun, 08 Mar 2009 12:08:49 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > width of 200. The default-to-80-columns would do the wrong thing. Text formatted for 200-columns is basically illegible. So I find it harsh to call it "the wrong thing" to use 80 columns in this context. Stefan From eliz@gnu.org Sun Mar 8 13:01:20 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 20:01:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout1.012.net.il (mtaout1.012.net.il [84.95.2.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28K1GeX012486 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 13:01:18 -0700 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KG700900CH74A00@i-mtaout1.012.net.il> for 2588@emacsbugs.donarmstrong.com; Sun, 08 Mar 2009 22:01:51 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KG700I57EAV1SC0@i-mtaout1.012.net.il>; Sun, 08 Mar 2009 22:01:45 +0200 (IST) Date: Sun, 08 Mar 2009 22:01:05 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: <87ljrfolb1.fsf@cyd.mit.edu> X-012-Sender: halo1@inter.net.il To: Chong Yidong Cc: drew.adams@oracle.com, 2588@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> <87ljrfolb1.fsf@cyd.mit.edu> > From: Chong Yidong > Cc: drew.adams@oracle.com, 2588@emacsbugs.donarmstrong.com > Date: Sun, 08 Mar 2009 15:40:18 -0400 > > Eli Zaretskii writes: > > > Anyway, I wouldn't go for such adventures before Emacs 23.1 is > > released. Until then, I'd simply not set COLUMNS when pop-up-frames > > is non-nil. > > I'm not sure we should make *any* change to this before the release. Going back to Emacs 20 behavior for pop-up-frames seems safe enough. But it's your call. From eliz@gnu.org Sun Mar 8 13:03:43 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 20:03:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout1.012.net.il (mtaout1.012.net.il [84.95.2.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28K3eSt012590 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 13:03:42 -0700 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KG700F00DGUYX00@i-mtaout1.012.net.il> for 2588@emacsbugs.donarmstrong.com; Sun, 08 Mar 2009 22:04:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KG7006YEEF48860@i-mtaout1.012.net.il>; Sun, 08 Mar 2009 22:04:18 +0200 (IST) Date: Sun, 08 Mar 2009 22:03:38 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Cc: cyd@stupidchicken.com, 2588@debbugs.gnu.org, drew.adams@oracle.com Reply-to: Eli Zaretskii Message-id: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <871vt86ms0.fsf@cyd.mit.edu> > From: Stefan Monnier > Cc: Eli Zaretskii , 2588@emacsbugs.donarmstrong.com, Drew Adams > Date: Sun, 08 Mar 2009 15:43:39 -0400 > > > This is explained in the code comments: it's required to ensure that the > > output of the manpage formatter has the same number of columns as the > > Emacs window/frame. > > Well, that part I understood, even without the comment ;-) > The question is: what was the motivation to adjust the number of columns > to that of the Emacs window/frame? Does the following comment from man.el explain it to you? ;; This isn't strictly correct, since we don't know how ;; the page will actually be displayed, but it seems ;; reasonable. Translation: don't have a better idea, so why not? From eliz@gnu.org Sun Mar 8 13:04:12 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 20:04:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout1.012.net.il (mtaout1.012.net.il [84.95.2.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28K49Ng012642 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 13:04:11 -0700 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KG700I00DYIIC00@i-mtaout1.012.net.il> for 2588@emacsbugs.donarmstrong.com; Sun, 08 Mar 2009 22:04:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KG70061NEFX8870@i-mtaout1.012.net.il>; Sun, 08 Mar 2009 22:04:46 +0200 (IST) Date: Sun, 08 Mar 2009 22:04:07 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Cc: cyd@stupidchicken.com, 2588@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> > From: Stefan Monnier > Cc: 2588@emacsbugs.donarmstrong.com, Eli Zaretskii > Date: Sun, 08 Mar 2009 15:45:46 -0400 > > > width of 200. The default-to-80-columns would do the wrong thing. > > Text formatted for 200-columns is basically illegible. So I find it > harsh to call it "the wrong thing" to use 80 columns in this context. Agreed. From drew.adams@oracle.com Sun Mar 8 13:16:53 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 20:16:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=FOURLA,GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28KGoF7017194 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 13:16:51 -0700 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n28KHMBj001630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Mar 2009 20:17:23 GMT Received: from acsmt701.oracle.com (acsmt701.oracle.com [141.146.40.71]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n28KGt7T031712; Sun, 8 Mar 2009 20:16:56 GMT Received: from dradamslap1 (/141.144.168.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Mar 2009 20:16:39 +0000 From: "Drew Adams" To: "'Chong Yidong'" Cc: "'Eli Zaretskii'" , <2588@debbugs.gnu.org> References: <873adqnery.fsf@cyd.mit.edu><001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu><000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> Subject: RE: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Date: Sun, 8 Mar 2009 13:16:40 -0700 Message-ID: <002501c9a02a$cb2c79d0$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87y6vfomw5.fsf@cyd.mit.edu> Thread-Index: AcmgINdmY6DP7rckSa68CmFe4t8FwgAA4RmQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt701.oracle.com [141.146.40.71] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.49B427A9.027C:SCFSTAT928724,ss=1,fgs=0 > > Please do not set COLUMNS to any value that is designed for frames - > > that includes `default-frame-alist'. COLUMNS is about buffer text > > formatting, not about frame sizing. > > > > The formatting width for the `Man' buffer, like that of for > > the *Help* buffer or the *Apropos* buffer or others, should > > have *nothing to do* with the width of any window or frame > > parameter - existing or default. The point of that sentence, which your response below ignores, is that window and frame metrics are *irrelevant* to text formatting of the `man' output. > The `man' facility is different from apropos or help---the text is > generated by an external formatter, not by Emacs. So what? That doesn't change the principle. At most, it changes how the text formatting is done - not what should be used to determine which formatting is to be used. You are twisting things, here. The issue is not who (`man' vs Emacs) actually formats the text. The issue is what should be the source for the COLUMNS value. *Help* and *Apropos* use fixed values; they do not use a value that depend on what they guess the displaying window or frame might be like. > If COLUMNS is omitted, the formatter output is too long > for the frame width, on at least one (Debian) system. No one but you has mentioned *omitting* COLUMNS. That is a red herring. The question is what value should be used for COLUMNS - that's all. Where should that value come from? You don't address that. This omission suggests you think that just because COLUMNS needs to be defined, it should be taken from a frame parameter. That doesn't follow, at all. > Setting COLUMNS to the frame width does the right thing most of the > time, Nonsense. You haven't even named one context for which it does the right thing, let alone supported the assertion that it DTRT most of the time. (Where "most of the time" can only mean most of the time that COLUMNS is not defined otherwise.) I would argue that whenever `frame-width' is used here it either has a negative effect or it has no effect. AFAICT, it never adds anything useful. And, in any case, "most of the time" is not good enough, if the behavior is, as it is, badly bugged for other cases. Besides, there is absolutely no reason for this behavior, even in the cases where it does not present a problem. It is illogical and un-Emacs to couple the text formatting to some window or frame size. > and covers more cases than a hardcoded value. It's true that it > can fail for the pop-up-frames case, and we can work around that by > using default-frame-alist. No, that is precisely the wrong thing to do. That continues the mistake of using a frame parameter for text formatting decisions. Completely uncalled for. > Certainly, it's always possible to come up > with a special setup that makes this heuristic fail. But if you're > setup is so special, just set Man-width and be done with it. This has nothing to do with my setup. Stop trying to make this sound like something special for weird ol' Drew. I told you that my interest here is fixing Emacs, not customizing my setup. And I mentioned that I rarely use `man' myself nowadays. This has nothing to do with my own use of Emacs. This becomes ad hominem argument. This is not about Drew. You are distorting the discussion, throwing out red herrings, ignoring straightforward arguments made by others, and trying to give the impression that this is just a corner case - or worse, just a case of customization due to odd personal preferences or individual setup. Please listen: The buffer text formatting should not be based on a window or frame measurement or setting. COLUMNS should be based on user choice (e.g. `Man-width') or, failing that, on some buffer text-formatting setting (e.g. `fill-column' or 80). From drew.adams@oracle.com Sun Mar 8 13:17:17 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 20:17:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28KHEHg017226 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 13:17:15 -0700 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n28KJqtT031451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Mar 2009 20:19:53 GMT Received: from acsmt706.oracle.com (acsmt706.oracle.com [141.146.40.84]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n28KHJbN032052; Sun, 8 Mar 2009 20:17:20 GMT Received: from dradamslap1 (/141.144.168.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Mar 2009 20:17:04 +0000 From: "Drew Adams" To: "'Eli Zaretskii'" , "'Stefan Monnier'" Cc: , <2588@debbugs.gnu.org> References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <871vt86ms0.fsf@cyd.mit.edu> Subject: RE: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Date: Sun, 8 Mar 2009 13:17:04 -0700 Message-ID: <002601c9a02a$d9a30560$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcmgKRcx6WhE2jBtR4mmA2JVo7gHeAAAJVqg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt706.oracle.com [141.146.40.84] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.49B427C1.02EA:SCFSTAT928724,ss=1,fgs=0 > > Well, that part I understood, even without the comment ;-) > > The question is: what was the motivation to adjust the > > number of columns to that of the Emacs window/frame? > > Does the following comment from man.el explain it to you? > > ;; This isn't strictly correct, since we don't know how > ;; the page will actually be displayed, but it seems > ;; reasonable. > > Translation: don't have a better idea, so why not? The motivation expressed by that commentary is itself misguided. How the page will actually be displayed (in terms of window/frame size) is irrelevant to how to format the buffer text. That is precisely the mistake that is being made here. IOW, the problem is not just that the code is inadequate to the intention. The problem is that the intention itself is misguided. From drew.adams@oracle.com Sun Mar 8 13:17:23 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 8 Mar 2009 20:17:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=FOURLA,GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n28KHKwL017231 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 13:17:21 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n28KGv98016554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Mar 2009 20:16:59 GMT Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n28KHE4s010483; Sun, 8 Mar 2009 20:17:15 GMT Received: from dradamslap1 (/141.144.168.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Mar 2009 20:17:10 +0000 From: "Drew Adams" To: "'Chong Yidong'" , "'Eli Zaretskii'" Cc: <2588@debbugs.gnu.org> References: <873adqnery.fsf@cyd.mit.edu><001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu><000101c9a00a$3935bcf0$0200a8c0@us.oracle.com><87y6vfomw5.fsf@cyd.mit.edu> <87ljrfolb1.fsf@cyd.mit.edu> Subject: RE: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Date: Sun, 8 Mar 2009 13:17:10 -0700 Message-ID: <002701c9a02a$dd44e440$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ljrfolb1.fsf@cyd.mit.edu> Thread-Index: AcmgJawy16DQFirDQfGV/c0enAcE/QAAKp2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt707.oracle.com [141.146.40.85] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.49B427C7.02FF:SCFSTAT928724,ss=1,fgs=0 > > Anyway, I wouldn't go for such adventures before Emacs 23.1 is > > released. Until then, I'd simply not set COLUMNS when pop-up-frames > > is non-nil. > > I'm not sure we should make *any* change to this before the release. Why? Why is fixing this bug an "adventure"? Just set COLUMNS to 80 in the places you currently set it to the previous `frame-width'. There is no case where using the previous frame's width DTRT for the text formatting, and there are cases where it does the wrong thing. And the fix is simple. The code after the fix will be just as good in the cases where there is no bug today, and it will remove the bugged case. The code will also be much simpler. This is just a case of removing inappropriate cruft. It's one thing to put off either wish-list enhancements or complex bug fixes before the release. I see no reason this fix can't be applied now. You claimed the code and the fix are non-trivial, but that doesn't seem to be the case. From monnier@iro.umontreal.ca Sun Mar 8 20:27:14 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 9 Mar 2009 03:27:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.5 required=4.0 tests=GENDER,HAS_BUG_NUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n293RBIl000672 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 20:27:12 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogFAGMptElLd/DG/2dsb2JhbACBTs92hAUGhCE X-IronPort-AV: E=Sophos;i="4.38,327,1233550800"; d="scan'208";a="34874090" Received: from 75-119-240-198.dsl.teksavvy.com (HELO pastel.home) ([75.119.240.198]) by ironport2-out.teksavvy.com with ESMTP; 08 Mar 2009 23:27:05 -0400 Received: by pastel.home (Postfix, from userid 20848) id 8687C7FA2; Sun, 8 Mar 2009 23:27:04 -0400 (EDT) From: Stefan Monnier To: Chong Yidong Cc: 2588@debbugs.gnu.org, Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Message-ID: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> <87ljrfolb1.fsf@cyd.mit.edu> Date: Sun, 08 Mar 2009 23:27:04 -0400 In-Reply-To: <87ljrfolb1.fsf@cyd.mit.edu> (Chong Yidong's message of "Sun, 08 Mar 2009 15:40:18 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> Anyway, I wouldn't go for such adventures before Emacs 23.1 is >> released. Until then, I'd simply not set COLUMNS when pop-up-frames >> is non-nil. > I'm not sure we should make *any* change to this before the release. We should at least make this "auto adjust man width to match window width" configurable, since (even if it were implemented correctly) it doesn't necessarily do what the user wants. Stefan From cyd@stupidchicken.com Sun Mar 8 20:36:51 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 9 Mar 2009 03:36:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n293amDQ003180 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 20:36:50 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 143E957E205; Sun, 8 Mar 2009 23:38:01 -0400 (EDT) From: Chong Yidong To: Stefan Monnier Cc: 2588@debbugs.gnu.org, Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> <87ljrfolb1.fsf@cyd.mit.edu> Date: Sun, 08 Mar 2009 23:38:01 -0400 In-Reply-To: (Stefan Monnier's message of "Sun, 08 Mar 2009 23:27:04 -0400") Message-ID: <87eix7fjs6.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Stefan Monnier writes: > We should at least make this "auto adjust man width to match window > width" configurable, since (even if it were implemented correctly) it > doesn't necessarily do what the user wants. Man-width can be set to an integer. From eliz@gnu.org Sun Mar 8 21:03:41 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 9 Mar 2009 04:03:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout7.012.net.il (mtaout7.012.net.il [84.95.2.19]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n2943bQP009438 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 21:03:38 -0700 Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KG8009000GGXV00@i-mtaout7.012.net.il> for 2588@emacsbugs.donarmstrong.com; Mon, 09 Mar 2009 06:03:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KG8001JV0M32230@i-mtaout7.012.net.il>; Mon, 09 Mar 2009 06:03:40 +0200 (IST) Date: Mon, 09 Mar 2009 06:03:35 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: <002501c9a02a$cb2c79d0$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Cc: cyd@stupidchicken.com, 2588@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> <002501c9a02a$cb2c79d0$0200a8c0@us.oracle.com> > From: "Drew Adams" > Cc: "'Eli Zaretskii'" , <2588@emacsbugs.donarmstrong.com> > Date: Sun, 8 Mar 2009 13:16:40 -0700 > > > If COLUMNS is omitted, the formatter output is too long > > for the frame width, on at least one (Debian) system. > > No one but you has mentioned *omitting* COLUMNS. In all fairness, I mentioned it. From eliz@gnu.org Sun Mar 8 21:05:50 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 9 Mar 2009 04:05:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout2.012.net.il (mtaout2.012.net.il [84.95.2.4]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n2945kUQ011384 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 21:05:48 -0700 Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KG800C000KUIQ00@i_mtaout2.012.net.il> for 2588@emacsbugs.donarmstrong.com; Mon, 09 Mar 2009 06:06:23 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.192.247]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KG8008HE0QEUPE1@i_mtaout2.012.net.il>; Mon, 09 Mar 2009 06:06:23 +0200 (IST) Date: Mon, 09 Mar 2009 06:05:34 +0200 From: Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-reply-to: <002701c9a02a$dd44e440$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Cc: cyd@stupidchicken.com, 2588@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> <87ljrfolb1.fsf@cyd.mit.edu> <002701c9a02a$dd44e440$0200a8c0@us.oracle.com> > From: "Drew Adams" > Cc: <2588@emacsbugs.donarmstrong.com> > Date: Sun, 8 Mar 2009 13:17:10 -0700 > > > > Anyway, I wouldn't go for such adventures before Emacs 23.1 is > > > released. Until then, I'd simply not set COLUMNS when pop-up-frames > > > is non-nil. > > > > I'm not sure we should make *any* change to this before the release. > > Why? Why is fixing this bug an "adventure"? I used the word "adventure", and I meant the suggestion to guess the right value for COLUMNS from default-frame-alist or pop-up-frame-alist. I think, even if this is correct, it's too complex for now. From drew.adams@oracle.com Sun Mar 8 22:33:18 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 9 Mar 2009 05:33:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n295XFqO000706 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 22:33:16 -0700 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n295ZrdN017513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Mar 2009 05:35:54 GMT Received: from acsmt701.oracle.com (acsmt701.oracle.com [141.146.40.71]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n295XKIg011672; Mon, 9 Mar 2009 05:33:21 GMT Received: from dradamslap1 (/141.144.168.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Mar 2009 05:33:04 +0000 From: "Drew Adams" To: "'Eli Zaretskii'" Cc: , <2588@debbugs.gnu.org> References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> <002501c9a02a$cb2c79d0$0200a8c0@us.oracle.com> Subject: RE: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Date: Sun, 8 Mar 2009 22:33:10 -0700 Message-ID: <004f01c9a078$89446390$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcmgbDMKsOvuy6AQS0Kqa8IW2pYKHAAC2SQA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt701.oracle.com [141.146.40.71] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B020A.49B4AA12.00CE:SCFSTAT928724,ss=1,fgs=0 > > > If COLUMNS is omitted, the formatter output is too long > > > for the frame width, on at least one (Debian) system. > > > > No one but you has mentioned *omitting* COLUMNS. > > In all fairness, I mentioned it. Sorry, I missed that suggestion on your part. Maybe that's what you meant when you suggested perhaps going back to Emacs 20 behavior? I thought you meant that the visible behavior, not the code, would be like that of Emacs 20. Yes, I guess if the code were reverted to be like Emacs 20, then more modern `man' behavior, which uses COLUMN, would no longer have the same effect as before. Or maybe I'm still missing what you meant. At any rate, omitting COLUMNS was not a fix I was suggesting. I should have left it at that. From drew.adams@oracle.com Sun Mar 8 22:33:29 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 9 Mar 2009 05:33:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GENDER,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n295XQYd000714 for <2588@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 22:33:27 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n295a4Ad017773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Mar 2009 05:36:05 GMT Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n295XIY0010204; Mon, 9 Mar 2009 05:33:19 GMT Received: from dradamslap1 (/141.144.168.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Mar 2009 05:33:14 +0000 From: "Drew Adams" To: "'Eli Zaretskii'" Cc: , <2588@debbugs.gnu.org> References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> <87ljrfolb1.fsf@cyd.mit.edu> <002701c9a02a$dd44e440$0200a8c0@us.oracle.com> Subject: RE: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Date: Sun, 8 Mar 2009 22:33:18 -0700 Message-ID: <005001c9a078$8f18d9e0$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcmgbIxyB3+Zfwn6TGqFQ2Vl6o4JiAAC6HlA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt704.oracle.com [141.146.40.82] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0206.49B4AA1C.00F9:SCFSTAT928724,ss=1,fgs=0 > > > > Anyway, I wouldn't go for such adventures before Emacs 23.1 is > > > > released. Until then, I'd simply not set COLUMNS when > > > > pop-up-frames is non-nil. > > > > > > I'm not sure we should make *any* change to this before > > > the release. > > > > Why? Why is fixing this bug an "adventure"? > > I used the word "adventure", and I meant the suggestion to guess the > right value for COLUMNS from default-frame-alist or > pop-up-frame-alist. I think, even if this is correct, it's too > complex for now. That would be not only an adventure but misguided. Window and frame metrics and parameters are not appropriate models for buffer text formatting. From monnier@iro.umontreal.ca Mon Mar 9 06:29:06 2009 Received: (at 2588) by emacsbugs.donarmstrong.com; 9 Mar 2009 13:29:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.5 required=4.0 tests=GENDER,HAS_BUG_NUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n29DT377028621 for <2588@emacsbugs.donarmstrong.com>; Mon, 9 Mar 2009 06:29:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAAO2tElLd/DG/2dsb2JhbACBTs9FhAUGhCE X-IronPort-AV: E=Sophos;i="4.38,329,1233550800"; d="scan'208";a="34884797" Received: from 75-119-240-198.dsl.teksavvy.com (HELO pastel.home) ([75.119.240.198]) by ironport2-out.teksavvy.com with ESMTP; 09 Mar 2009 09:28:58 -0400 Received: by pastel.home (Postfix, from userid 20848) id C68AD7FA2; Mon, 9 Mar 2009 09:28:57 -0400 (EDT) From: Stefan Monnier To: Chong Yidong Cc: 2588@debbugs.gnu.org, Eli Zaretskii Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Message-ID: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> <87ljrfolb1.fsf@cyd.mit.edu> <87eix7fjs6.fsf@cyd.mit.edu> Date: Mon, 09 Mar 2009 09:28:57 -0400 In-Reply-To: <87eix7fjs6.fsf@cyd.mit.edu> (Chong Yidong's message of "Sun, 08 Mar 2009 23:38:01 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> We should at least make this "auto adjust man width to match window >> width" configurable, since (even if it were implemented correctly) it >> doesn't necessarily do what the user wants. > Man-width can be set to an integer. Good point. So let's default it to 80: this will bring back Emacs-21's behavior and if people want the other one, they can set it to nil. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 11 17:59:22 2011 Received: (at 2588) by debbugs.gnu.org; 11 Sep 2011 21:59:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2s3d-000629-64 for submit@debbugs.gnu.org; Sun, 11 Sep 2011 17:59:22 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2s3Y-00061p-Fi for 2588@debbugs.gnu.org; Sun, 11 Sep 2011 17:59:18 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R2rzI-0001x8-AG; Sun, 11 Sep 2011 23:54:52 +0200 From: Lars Magne Ingebrigtsen To: Stefan Monnier Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-Reply-To: (Stefan Monnier's message of "Sun, 08 Mar 2009 15:45:46 -0400") Date: Sun, 11 Sep 2011 23:51:44 +0200 Message-ID: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-Now-Playing: Alasdair Roberts's _Spoils_: "Unyoked Oxen Turn" MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1R2rzI-0001x8-AG X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1316382892.39529@bAJu14dIq0qI/9/S++ytCQ X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 2588 Cc: Chong Yidong , Eli Zaretskii , 2588@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Stefan Monnier writes: >> width of 200. The default-to-80-columns would do the wrong thing. > > Text formatted for 200-columns is basically illegible. So I find it > harsh to call it "the wrong thing" to use 80 columns in this context. As far as I can tell from this thread, most people agreed that Man didn't do the right thing here, but nobody wanted to fix it, since Emacs 23.1 was too close. Did anything more happen here afterwards? Is this still buggy? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 14:55:47 2011 Received: (at 2588) by debbugs.gnu.org; 15 Sep 2011 18:55:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R4H69-00041y-Ur for submit@debbugs.gnu.org; Thu, 15 Sep 2011 14:55:47 -0400 Received: from smarty.dreamhost.com ([208.113.175.8]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R4H5s-000414-BH for 2588@debbugs.gnu.org; Thu, 15 Sep 2011 14:55:35 -0400 Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id 5689E6E8097; Thu, 15 Sep 2011 11:50:48 -0700 (PDT) Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 657B8451C3FB; Thu, 15 Sep 2011 11:50:47 -0700 (PDT) From: Juri Linkov To: Lars Magne Ingebrigtsen Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Organization: JURTA References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> Date: Thu, 15 Sep 2011 21:45:31 +0300 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sun, 11 Sep 2011 23:51:44 +0200") Message-ID: <8762kt4tmo.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 2588 Cc: 2588@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > Did anything more happen here afterwards? Is this still buggy? Is this the same as bug#9084? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 17 01:33:51 2011 Received: (at 2588) by debbugs.gnu.org; 17 Sep 2011 05:33:52 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R4nXD-00017o-K5 for submit@debbugs.gnu.org; Sat, 17 Sep 2011 01:33:51 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R4nX8-00017X-PP for 2588@debbugs.gnu.org; Sat, 17 Sep 2011 01:33:47 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R4nSO-0001Yq-G9; Sat, 17 Sep 2011 07:28:52 +0200 From: Lars Magne Ingebrigtsen To: Juri Linkov Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-Reply-To: <8762kt4tmo.fsf@mail.jurta.org> (Juri Linkov's message of "Thu, 15 Sep 2011 21:45:31 +0300") Date: Sat, 17 Sep 2011 07:22:05 +0200 Message-ID: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <8762kt4tmo.fsf@mail.jurta.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEVFAQVKQ0q1rbPr5+og Gh9mX2c4LzYeCg8cFRoZExdEPkQYEBVObJmEAAACZUlEQVQ4jW3Uv2vbQBQH8BuC2zEHiTG35YyW bpHoHsPVVZulNtwegiuDunSKBy8tHERq10J00RKRYBJlK0kc9f1zfe9OEvTH2/w+9+4r+85iRmVY cfZ3sX86PdR9bWa8K/EH3B30sIfAe1i+7uEeoaqF8HAR9XBMIDivKopYRV2IAINAfZIRRIddBCgP SLxaQtSF3LfAheCCf4eoCzkmSLEnsIbbddSGCChboJkR4IQP2WtyhKTyq5YrBB9yV2QI05raXJwT +JB3WUyQug9D2BJQiCiMQlAJjfDRak1w6H4oRWAc1J/WFO5Cbo2HaVrjFz8GByFCrBzQXhXfgAcM ETiwQHhWSVqLG+yXBAd8T6nEgZkmKb8tG1uOIykDfqOmSYLQmCM2qF+usBhj8lW1VImHAuHkBWMO 9FV6dNbBFzZgVIjsA0vYwAPYi887PewyxRgCniDAdrWz62cY27BzB8rDmd6/GpwQLN5i0sBDCfBV z7UWC62HSmXv66SHj1oHerbRs0Uc4znUbQaA1lri8v0h3XDFxcZnwANBoEV6E1uUStQtPCLMpZ5N F/kzwoTXGw9vHAQzFZcE33AvD9qDNjnQX8Nw7uGJQEupbekA76CHRx0Ecz2WQQNNVtgcQ4SD07mk CgMAjLC2uGzB92UkAQoqa/B4WbZ9ki2ECJklqThNPLYwDqHJrasJwfa0gwga187tJY9ZtpZdOQB8 KvuD4Ckc03IHuBytsGWF8DOMxlh0p8CWZdMg5BPMuA6jyPcRGsD7VeT5L5wYy1C2m0Fb1j7E/iWD l9gY1b+CjDLxf94+MUIc/wYlC6YCrvIGEQAAAABJRU5ErkJggg== X-Now-Playing: Ikonika's _Contact, Love, Want, Have_: "Yoshimitsu" MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1R4nSO-0001Yq-G9 X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1316842132.55876@dKQzsa71Im67lrlJ4sRPQQ X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 2588 Cc: 2588@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Juri Linkov writes: >> Did anything more happen here afterwards? Is this still buggy? > > Is this the same as bug#9084? Looks quite similar. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 18:01:13 2011 Received: (at control) by debbugs.gnu.org; 6 Oct 2011 22:01:13 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBw08-0002Xr-HD for submit@debbugs.gnu.org; Thu, 06 Oct 2011 18:01:12 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBw06-0002Xk-C8 for control@debbugs.gnu.org; Thu, 06 Oct 2011 18:01:11 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1RBvzp-0002il-MW for control@debbugs.gnu.org; Fri, 07 Oct 2011 00:00:53 +0200 Date: Fri, 07 Oct 2011 00:00:53 +0200 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #9084 X-MailScanner-ID: 1RBvzp-0002il-MW X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1318543253.8054@2b3gcaygBF2GdMvvyOb9Ng X-Spam-Status: No X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) forcemerge 9084 2588 From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 18:14:58 2011 Received: (at 2588) by debbugs.gnu.org; 6 Oct 2011 22:14:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBwDR-0002uz-UG for submit@debbugs.gnu.org; Thu, 06 Oct 2011 18:14:58 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBwDM-0002uN-6L for 2588@debbugs.gnu.org; Thu, 06 Oct 2011 18:14:53 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1RBwD3-0002xw-5I; Fri, 07 Oct 2011 00:14:33 +0200 From: Lars Magne Ingebrigtsen To: Stefan Monnier Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sun, 11 Sep 2011 23:51:44 +0200") Date: Fri, 07 Oct 2011 00:02:41 +0200 Message-ID: References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) X-Now-Playing: Clogs's _The Creatures in the Garden of Lady Walton_: "On the Edge" MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1RBwD3-0002xw-5I X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1318544073.25323@6NPqMFpzGMOalqcL9gVgzA X-Spam-Status: No X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 2588 Cc: Chong Yidong , Eli Zaretskii , 2588@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Lars Magne Ingebrigtsen writes: >>> width of 200. The default-to-80-columns would do the wrong thing. >> >> Text formatted for 200-columns is basically illegible. So I find it >> harsh to call it "the wrong thing" to use 80 columns in this context. > > As far as I can tell from this thread, most people agreed that Man > didn't do the right thing here, but nobody wanted to fix it, since Emacs > 23.1 was too close. > > Did anything more happen here afterwards? Is this still buggy? Juri Linkov writes: >> Did anything more happen here afterwards? Is this still buggy? > > Is this the same as bug#9084? And it is, I think. Is there a particular reason why we don't just use `frame-width' in these circumstances? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 22:17:47 2011 Received: (at 2588) by debbugs.gnu.org; 7 Oct 2011 02:17:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RC00O-00040g-Ux for submit@debbugs.gnu.org; Thu, 06 Oct 2011 22:17:46 -0400 Received: from smarty.dreamhost.com ([208.113.175.8]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RC00L-00040N-T0 for 2588@debbugs.gnu.org; Thu, 06 Oct 2011 22:17:42 -0400 Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id A6C766E807A; Thu, 6 Oct 2011 19:17:29 -0700 (PDT) Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 66709451C535; Thu, 6 Oct 2011 19:17:27 -0700 (PDT) From: Juri Linkov To: Lars Magne Ingebrigtsen Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Organization: JURTA References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> Date: Fri, 07 Oct 2011 03:34:51 +0300 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Fri, 07 Oct 2011 00:02:41 +0200") Message-ID: <87sjn5ftxs.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 2588 Cc: Stefan Monnier , 2588@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) >>> Did anything more happen here afterwards? Is this still buggy? >> >> Is this the same as bug#9084? > > And it is, I think. Is there a particular reason why we don't just use > `frame-width' in these circumstances? On 07 Mar 2009 in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2588#60 Stefan said: We could try to fix this: I think it would actually be desirable to pop up the frame immediately and then asynchronously fill it as man's output comes in. On 11 Jan 2010 I posted a patch that implements asynchronous formatting in the immediately displayed Man buffer in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5054#76 (see subthread with the subject "Man truncated", please don't merge bug#5054 because its initial report was about a different problem). Is it time to install this patch now? It fixes the problem with wrong widths in a new window/frame. Though it doesn't implement formatting on the fly from the process-filter, but maybe this could be implemented later in 24.2? From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 10 13:38:43 2012 Received: (at 2588) by debbugs.gnu.org; 10 Jan 2012 18:38:43 +0000 Received: from localhost ([127.0.0.1]:52751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rkgao-0002M3-QA for submit@debbugs.gnu.org; Tue, 10 Jan 2012 13:38:43 -0500 Received: from fencepost.gnu.org ([140.186.70.10]:47965) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rkgan-0002Lu-Ct for 2588@debbugs.gnu.org; Tue, 10 Jan 2012 13:38:41 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RkgaS-0002SM-6M; Tue, 10 Jan 2012 13:38:20 -0500 From: Glenn Morris To: Chong Yidong Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> X-Spook: Comirex George W. Bush bomb Vickie Weaver SHA Belknap X-Ran: |/o.#mRe71d]>Ou+/:Zh?k3*$wFXC-f.Osng3~'oCq?LRzo.PK^Ng8Vwpb6qh!uy1fWab/ X-Hue: red X-Attribution: GM Date: Tue, 10 Jan 2012 13:38:20 -0500 In-Reply-To: <87y6vfomw5.fsf@cyd.mit.edu> (Chong Yidong's message of "Sun, 08 Mar 2009 15:06:02 -0400") Message-ID: <968vlf768z.fsf@fencepost.gnu.org> User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 2588 Cc: 2588@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Chong Yidong wrote: > The `man' facility is different from apropos or help---the text is > generated by an external formatter, not by Emacs. If COLUMNS is > omitted, the formatter output is too long for the frame width, on at > least one (Debian) system. Not to to dredge up this overly-long thread, but a few weeks ago man was changed to _not_ set COLUMNS under a window-system, which seems incorrect in light of the above. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 10 13:39:43 2012 Received: (at 2588) by debbugs.gnu.org; 10 Jan 2012 18:39:43 +0000 Received: from localhost ([127.0.0.1]:52756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rkgbm-0002Nj-HD for submit@debbugs.gnu.org; Tue, 10 Jan 2012 13:39:43 -0500 Received: from fencepost.gnu.org ([140.186.70.10]:48015) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rkgbk-0002Nd-RD for 2588@debbugs.gnu.org; Tue, 10 Jan 2012 13:39:41 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RkgbP-0002YU-5x; Tue, 10 Jan 2012 13:39:19 -0500 From: Glenn Morris To: Chong Yidong Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> <000601c99f40$a47c9080$0200a8c0@us.oracle.com> <873adpazk9.fsf@cyd.mit.edu> <87wsb0m1ym.fsf@cyd.mit.edu> <000101c9a00a$3935bcf0$0200a8c0@us.oracle.com> <87y6vfomw5.fsf@cyd.mit.edu> <968vlf768z.fsf@fencepost.gnu.org> X-Spook: espionage Montenegro ASLET FIPS140 codes PGP monarchist X-Ran: ,Z@U}ia6$%K;6JERvOCX@NQ_UA|Jg02^n@4TA*]6{x#}2iV;T[BFbki2vQC0$#9w X-Hue: cyan X-Debbugs-No-Ack: yes X-Attribution: GM Date: Tue, 10 Jan 2012 13:39:19 -0500 In-Reply-To: <968vlf768z.fsf@fencepost.gnu.org> (Glenn Morris's message of "Tue, 10 Jan 2012 13:38:20 -0500") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 2588 Cc: 2588@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Glenn Morris wrote: > Not to to dredge up this overly-long thread, but a few weeks ago man was > changed to _not_ set COLUMNS under a window-system, which seems > incorrect in light of the above. Ignore me, I misread the code. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 22 12:31:45 2014 Received: (at control) by debbugs.gnu.org; 22 Jun 2014 16:31:45 +0000 Received: from localhost ([127.0.0.1]:57246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WykgD-0004f5-9Q for submit@debbugs.gnu.org; Sun, 22 Jun 2014 12:31:45 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:42517 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wykg9-0004et-3f for control@debbugs.gnu.org; Sun, 22 Jun 2014 12:31:43 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Wykg8-0006ru-N0 for control@debbugs.gnu.org; Sun, 22 Jun 2014 12:31:40 -0400 Date: Sun, 22 Jun 2014 12:31:40 -0400 Message-Id: Subject: control message for bug 17831 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) merge 9084 17831 From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 23 08:54:09 2014 Received: (at control) by debbugs.gnu.org; 23 Jun 2014 12:54:09 +0000 Received: from localhost ([127.0.0.1]:57756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wz3l6-00044T-7E for submit@debbugs.gnu.org; Mon, 23 Jun 2014 08:54:08 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:28109) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wz3kt-00043f-Q9; Mon, 23 Jun 2014 08:53:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCw4mEhQYDSSIBAjSGReOegeEOASpGYFqg0whgSwk X-IPAS-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCw4mEhQYDSSIBAjSGReOegeEOASpGYFqg0whgSwk X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="69215930" Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 Jun 2014 08:53:45 -0400 Received: by pastel.home (Postfix, from userid 20848) id 5F04D603CD; Mon, 23 Jun 2014 08:53:45 -0400 (EDT) From: Stefan Monnier To: Leo Liu Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width' Message-ID: References: Date: Mon, 23 Jun 2014 08:53:45 -0400 In-Reply-To: (Leo Liu's message of "Sun, 22 Jun 2014 21:30:45 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: control Cc: 17831@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) forcemerge 17831 2588 thanks > Man-width defaults to the window width at the time of running `man'. But > if the frame is split horizontally it usually leads to a view with the > right-hand-side half unviewable. Indeed. As discussed earlier, I think the right fix is to display the buffer right away and then fill it in the background. Problem with it, is that currently we do "fill the buffer with half-processed text; finish formatting; display", so if we only move the "display" part, the user will see (temporarily) the half-processed text. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 01 20:18:33 2014 Received: (at 2588-done) by debbugs.gnu.org; 2 Jul 2014 00:18:33 +0000 Received: from localhost ([127.0.0.1]:39714 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X28Fs-00049o-SP for submit@debbugs.gnu.org; Tue, 01 Jul 2014 20:18:33 -0400 Received: from alc-vshost7.dreamhost.com ([69.163.216.107]:58567 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X28Fp-00049P-Sq for 2588-done@debbugs.gnu.org; Tue, 01 Jul 2014 20:18:31 -0400 Received: from localhost.jurta.org (ps18281.dreamhostps.com [69.163.222.226]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 9D4DA30339951B; Tue, 1 Jul 2014 17:18:25 -0700 (PDT) From: Juri Linkov To: Stefan Monnier Subject: Re: bug#2588: 23.0.90; Man buffer improperly formatted - wrong width Organization: JURTA References: <873adqnery.fsf@cyd.mit.edu> <001001c99ee0$35257540$0200a8c0@us.oracle.com> Date: Wed, 02 Jul 2014 02:57:42 +0300 In-Reply-To: (Stefan Monnier's message of "Sat, 07 Mar 2009 23:05:08 -0500") Message-ID: <87y4wdo9ml.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Version: 24.4.50 >> The problem is, AFAICS, that with pop-up-frames `man' is run _before_ >> the frame to display its output is created. To do what you want we > > We could try to fix this: I think it would actually be desirable to pop > up the frame immediately and then asynchronously fill it as man's output > comes in. [...] Content analysis details: (2.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL [69.163.216.107 listed in zen.spamhaus.org] 1.6 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT [69.163.216.107 listed in bb.barracudacentral.org] X-Debbugs-Envelope-To: 2588-done Cc: 2588-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.4 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Version: 24.4.50 >> The problem is, AFAICS, that with pop-up-frames `man' is run _before_ >> the frame to display its output is created. To do what you want we > > We could try to fix this: I think it would actually be desirable to pop > up the frame immediately and then asynchronously fill it as man's output > comes in. [...] Content analysis details: (2.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL [69.163.216.107 listed in zen.spamhaus.org] 1.6 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT [69.163.216.107 listed in bb.barracudacentral.org] Version: 24.4.50 >> The problem is, AFAICS, that with pop-up-frames `man' is run _before_ >> the frame to display its output is created. To do what you want we > > We could try to fix this: I think it would actually be desirable to pop > up the frame immediately and then asynchronously fill it as man's output > comes in. Now this is implemented in bug#17831 merged with bug#2588, but to fix the original issue of running `man' with pop-up-frames in a frame that is 30 chars wide, required an additional change (now installed as well) to select the window after popping up the frame to get its real width (since display-buffer in Man-notify method `friendly' doesn't select the window): === modified file 'lisp/man.el' --- lisp/man.el 2014-05-09 07:02:00 +0000 +++ lisp/man.el 2014-07-01 23:54:32 +0000 @@ -1030,15 +1030,22 @@ (defmacro Man-start-calling (&rest body) ;; ther is available). (when (or window-system (not (or (getenv "MANWIDTH") (getenv "COLUMNS")))) - ;; This isn't strictly correct, since we don't know how - ;; the page will actually be displayed, but it seems - ;; reasonable. + ;; Since the page buffer is displayed beforehand, + ;; we can select its window and get the window/frame width. (setenv "COLUMNS" (number-to-string (cond ((and (integerp Man-width) (> Man-width 0)) Man-width) - (Man-width (frame-width)) - ((window-width)))))) + (Man-width + (if (window-live-p (get-buffer-window (current-buffer) t)) + (with-selected-window (get-buffer-window (current-buffer) t) + (frame-width)) + (frame-width))) + (t + (if (window-live-p (get-buffer-window (current-buffer) t)) + (with-selected-window (get-buffer-window (current-buffer) t) + (window-width)) + (window-width))))))) ;; Since man-db 2.4.3-1, man writes plain text with no escape ;; sequences when stdout is not a tty. In 2.5.0, the following ;; env-var was added to allow control of this (see Debian Bug#340673). From unknown Fri Aug 15 17:19:43 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 30 Jul 2014 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator