From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Llu=C3=ADs?= Newsgroups: gmane.emacs.bugs Subject: bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration Date: Fri, 01 Apr 2016 17:13:55 +0200 Message-ID: <87oa9t8iq4.fsf@fimbulvetr.bsc.es> References: <87bn5ug55o.fsf@fimbulvetr.bsc.es> <83egaqvbio.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1459523744 4003 80.91.229.3 (1 Apr 2016 15:15:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2016 15:15:44 +0000 (UTC) Cc: 23169@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 01 17:15:33 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1am0nK-0005D3-GZ for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Apr 2016 17:15:30 +0200 Original-Received: from localhost ([::1]:44992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am0nJ-0005yC-4u for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Apr 2016 11:15:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am0mw-0005TK-Om for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2016 11:15:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1am0ms-00039g-OG for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2016 11:15:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am0ms-00039a-Lg for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2016 11:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1am0ms-0002eU-D7 for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2016 11:15:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <87bn5ug55o.fsf@fimbulvetr.bsc.es> Resent-From: =?UTF-8?Q?Llu=C3=ADs?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Apr 2016 15:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23169 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23169-submit@debbugs.gnu.org id=B23169.145952364910114 (code B ref 23169); Fri, 01 Apr 2016 15:15:02 +0000 Original-Received: (at 23169) by debbugs.gnu.org; 1 Apr 2016 15:14:09 +0000 Original-Received: from localhost ([127.0.0.1]:47488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1am0m1-0002d4-79 for submit@debbugs.gnu.org; Fri, 01 Apr 2016 11:14:09 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:54555) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1am0ly-0002cT-QP for 23169@debbugs.gnu.org; Fri, 01 Apr 2016 11:14:07 -0400 Original-Received: from localhost ([84.88.51.85]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MYfJW-1aGkez1FoY-00VSKp; Fri, 01 Apr 2016 17:13:59 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-Provags-ID: V03:K0:V2c36TIFzrVmbfUGgy3vnU2p5fF+PglV8lDAf4vSGiccG8Sbjxz JL1kHdmk89j5515VSCb57HIyIcp+I25WICpawKBv/kgNGiuYSrP3oRrBetr3SZdJCRnFRhN lPqapXACebwjajdsfQfZp0UREDXu8RZBT71k5nMFzaNXrc3d4kU+LLjwFjcLWuM0RhdZc0b JjSo5ARwK3pFf0wR5BH/g== X-UI-Out-Filterresults: notjunk:1;V01:K0:CAitabLxyWk=:4BVRpUixhctRU1/eRn0Cgs bAgNX2OcMhZJQzJ4i5obO19IL2d7CTxgPOUikB+wd0V0+zcHVuszU4em5jUv8Hqfla33BD+RK nx7NIPgKP5YJXO+w8g+9vB25oIKRwa2ZS0gHLEGHmXytpTjmzbIQhQWB3QG57w7+by2LTHKyV Zn+OGskU3BGBSxBDPgemdwGwEN0DRjuVi+MrqouyonSADwyLImGRGKONKniu9kItzaH/TNyDP BFc7E2OkX44UMZc+T9yOIegqPja+0v1nFWHvrnJV6dOsGUfsr1lV/WZU8OIkVH43PZfuNc+ZB EF5N5uRUCKs0aiW0S+fKhVCSoWQwbFD7Yet+MvWnfo48J7LIGv9H0EAdi6mfg2voyoSLceb6N q3Vq4J32rTbrrX4m8A2fSZT26SdOs4muMuf04S2XC3U3IYiL06oQqeSwxQro+ZD6ihNxr5iLv LkFKa39N69cYQycY+JwC/LxF+hTIM8IOxb7pU5M9wjqu20kLlM6bKAu9cSScISq8zzxy9f/y4 E3Ss0d1XdUo1zYK3KEARz7SiqpcUx85VrYHc5CPjLqqZSUel9StGDX2p/+QbPvgtWrrEmHiMs MVmFUenF9XE2HxPqRXHAeEiQRfhz4s8ypvG7N9JPPwYprUQ87kNA1Ise0QGK9Bx/OmGx2eQVQ CLzwwrA4bfNmzy5/4GhyE553YWWI0RmdCJcE6zqw/HEEXxK9quNcF2Gnz7lJDYaUroDhmId/a 5IXa0Njw90gb4UHZNfWRnopOW9gn457eRtSRnFswpLE2HTz9E1S65qAbEro8fxNnrkVRE1u9 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115843 Archived-At: Eli Zaretskii writes: >> From: Llu=C3=ADs >> Date: Thu, 31 Mar 2016 15:15:15 +0200 >>=20 >> Before the man process is started, "Man-start-calling" calculates the "C= OLUMNS" >> envvar using "window-width" before splitting windows. The window split h= appens >> later once the process finishes, and the buffer is shown through >> "Man-notify-when-ready". >>=20 >> Assuming the buffer is going to be shown on a vertical split, the text w= ill go >> beyond the window limits if there was no other window in the frame (or i= f a new >> window is used), or will be reflowed with the proper width if an existin= g window >> is reused. >>=20 >> Manually calling "Man-update-manpage" fixes it, but it's annoying. Simpl= y adding >> a call to "Man-update-manpage" in "Man-notify-when-ready" would fix it >> ("(with-current-buffer man-buffer (Man-update-manpage))" in the "friendl= y" case >> for me). >>=20 >> As a bonus, this fix also reflows the text when an existing buffer is re= used. > Maybe I'm missing something, but won't your suggestion effectively > replace the background rendering of man pages with fully synchronous > one? Oh, that's true. > The usual way to fix these problems is to set Man-width to a non-nil > value, as appropriate for your frame/window dimensions. Would that > solve the problem for you? Thing is I don't know the width of the window that will be used, since in s= ome cases it does not exist yet: +-----+ +--+--+ | | | | | | | -> M-x man man -> | | | | | | | | +-----+ +--+--+ The ideal without breaking the asynchronicity would be to somehow display t= he new buffer on a window before populating it (display-buffer might or might = not reuse a window here), calculate its window's width, set COLUMNS, asynchrono= usly call man to populate the buffer, and then really show the buffer on the pre= vious window. The only problem is that creating a temporary window just to calculate its = width could annoy people because the contents won't be shown yet. Cheers, Lluis