GNU bug report logs - #23169
24.5; Inconsistent text reflow in man pages depending on window configuration

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23169 in the body.
You can then email your comments to 23169 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lluís <xscript <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; Inconsistent text reflow in man pages depending on window
 configuration
Date: Thu, 31 Mar 2016 15:15:15 +0200

Before the man process is started, "Man-start-calling" calculates the "COLUMNS"
envvar using "window-width" before splitting windows. The window split happens
later once the process finishes, and the buffer is shown through
"Man-notify-when-ready".

Assuming the buffer is going to be shown on a vertical split, the text will go
beyond the window limits if there was no other window in the frame (or if a new
window is used), or will be reflowed with the proper width if an existing window
is reused.

Manually calling "Man-update-manpage" fixes it, but it's annoying. Simply 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 "friendly" case
for me).

As a bonus, this fix also reflows the text when an existing buffer is reused.


Thanks,
  Lluis

Message #8 received at 23169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lluís <xscript <at> gmx.net>
Cc: 23169 <at> debbugs.gnu.org
Subject: Re: bug#23169: 24.5;
 Inconsistent text reflow in man pages depending on window
 configuration
Date: Thu, 31 Mar 2016 19:48:47 +0300

> From: Lluís <xscript <at> gmx.net>
> Date: Thu, 31 Mar 2016 15:15:15 +0200
> 
> Before the man process is started, "Man-start-calling" calculates the "COLUMNS"
> envvar using "window-width" before splitting windows. The window split happens
> later once the process finishes, and the buffer is shown through
> "Man-notify-when-ready".
> 
> Assuming the buffer is going to be shown on a vertical split, the text will go
> beyond the window limits if there was no other window in the frame (or if a new
> window is used), or will be reflowed with the proper width if an existing window
> is reused.
> 
> Manually calling "Man-update-manpage" fixes it, but it's annoying. Simply 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 "friendly" case
> for me).
> 
> As a bonus, this fix also reflows the text when an existing buffer is reused.

Maybe I'm missing something, but won't your suggestion effectively
replace the background rendering of man pages with fully synchronous
one?

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?

Message #11 received at 23169 <at> debbugs.gnu.org (full text, mbox):

From: Lluís <xscript <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23169 <at> debbugs.gnu.org
Subject: Re: bug#23169: 24.5;
 Inconsistent text reflow in man pages depending on window
 configuration
Date: Fri, 01 Apr 2016 17:13:55 +0200

Eli Zaretskii writes:

>> From: Lluís <xscript <at> gmx.net>
>> Date: Thu, 31 Mar 2016 15:15:15 +0200
>> 
>> Before the man process is started, "Man-start-calling" calculates the "COLUMNS"
>> envvar using "window-width" before splitting windows. The window split happens
>> later once the process finishes, and the buffer is shown through
>> "Man-notify-when-ready".
>> 
>> Assuming the buffer is going to be shown on a vertical split, the text will go
>> beyond the window limits if there was no other window in the frame (or if a new
>> window is used), or will be reflowed with the proper width if an existing window
>> is reused.
>> 
>> Manually calling "Man-update-manpage" fixes it, but it's annoying. Simply 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 "friendly" case
>> for me).
>> 
>> As a bonus, this fix also reflows the text when an existing buffer is reused.

> 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 some
cases it does not exist yet:

  +-----+                   +--+--+
  |     |                   |  |  |
  |     | -> M-x man man -> |  |  |
  |     |                   |  |  |
  +-----+                   +--+--+

The ideal without breaking the asynchronicity would be to somehow display the
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, asynchronously
call man to populate the buffer, and then really show the buffer on the previous
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

Message #14 received at 23169 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Lluís <xscript <at> gmx.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 23169 <at> debbugs.gnu.org
Subject: Re: bug#23169: 24.5; Inconsistent text reflow in man pages depending
 on window configuration
Date: Fri, 01 Apr 2016 18:20:36 +0200

> Thing is I don't know the width of the window that will be used, since in some
> cases it does not exist yet:
>
>    +-----+                   +--+--+
>    |     |                   |  |  |
>    |     | -> M-x man man -> |  |  |
>    |     |                   |  |  |
>    +-----+                   +--+--+
>
> The ideal without breaking the asynchronicity would be to somehow display the
> 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, asynchronously
> call man to populate the buffer, and then really show the buffer on the previous
> 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.

We could add a special alist element, say ‘pretend’, to ‘display-buffer’
that would cause the latter to return the size of the window where
BUFFER-OR-NAME would be displayed _without_ creating or touching that
window.  This will work reliably only if the new window

(1) appears on an existing frame (or we know that the window manager
reliably makes new frames just as large as we want them),

(2) is not created by a user-defined action (an action not predefined
in window.el) that does not understand ‘pretend’, and

(3) no window configuration or ‘display-buffer-alist’ related changes
are performed in the period from when the size was calculated until
‘display-buffer’ is called without "pretending".

martin

Message #17 received at 23169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lluís <xscript <at> gmx.net>
Cc: 23169 <at> debbugs.gnu.org
Subject: Re: bug#23169: 24.5;
 Inconsistent text reflow in man pages depending on window
 configuration
Date: Fri, 01 Apr 2016 20:40:40 +0300

> From: Lluís <xscript <at> gmx.net>
> Cc: 23169 <at> debbugs.gnu.org
> Date: Fri, 01 Apr 2016 17:13:55 +0200
> 
> > 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 some
> cases it does not exist yet:
> 
>   +-----+                   +--+--+
>   |     |                   |  |  |
>   |     | -> M-x man man -> |  |  |
>   |     |                   |  |  |
>   +-----+                   +--+--+

Isn't the window that man will use half of the window before the
command?  Then you know the width in advance, because you are familiar
with your window and frame configurations

> The ideal without breaking the asynchronicity would be to somehow display the
> 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, asynchronously
> call man to populate the buffer, and then really show the buffer on the previous
> 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.

Yes, that's the problem.

Message #20 received at 23169 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23169 <at> debbugs.gnu.org, Lluís <xscript <at> gmx.net>
Subject: Re: bug#23169: 24.5;
 Inconsistent text reflow in man pages depending on window
 configuration
Date: Fri, 01 Apr 2016 22:51:30 +0300

>> > 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 some
>> cases it does not exist yet:
>>
>>   +-----+                   +--+--+
>>   |     |                   |  |  |
>>   |     | -> M-x man man -> |  |  |
>>   |     |                   |  |  |
>>   +-----+                   +--+--+
>
> Isn't the window that man will use half of the window before the
> command?  Then you know the width in advance, because you are familiar
> with your window and frame configurations
>
>> The ideal without breaking the asynchronicity would be to somehow display the
>> 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, asynchronously
>> call man to populate the buffer, and then really show the buffer on the previous
>> 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.
>
> Yes, that's the problem.

That was the problem in 24.5 indeed, but fortunately it's fixed in 25.

Message #23 received at 23169 <at> debbugs.gnu.org (full text, mbox):

From: Lluís <xscript <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23169 <at> debbugs.gnu.org
Subject: Re: bug#23169: 24.5;
 Inconsistent text reflow in man pages depending on window
 configuration
Date: Sat, 02 Apr 2016 13:30:38 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii writes:

>> From: Lluís <xscript <at> gmx.net>
>> Cc: 23169 <at> debbugs.gnu.org
>> Date: Fri, 01 Apr 2016 17:13:55 +0200
>> 
>> > 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 some
>> cases it does not exist yet:
>> 
>> +-----+                   +--+--+
>> |     |                   |  |  |
>> |     | -> M-x man man -> |  |  |
>> |     |                   |  |  |
>> +-----+                   +--+--+

> Isn't the window that man will use half of the window before the
> command?  Then you know the width in advance, because you are familiar
> with your window and frame configurations

That's only one case. Maybe display-buffer ends up creating a smaller window
(depending on its configuration hooks), or maybe it ends up reusing some other
window.


>> The ideal without breaking the asynchronicity would be to somehow display the
>> 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, asynchronously
>> call man to populate the buffer, and then really show the buffer on the previous
>> 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.

> Yes, that's the problem.

Martin's "pretend" argument to display-buffer could be a way out of this
conundrum. Also, here's a patch for an alternative fix.


Thanks,
  Lluis

[man.el.patch (text/x-diff, inline)]

--- /tmp/old/man.el	2016-04-02 13:09:14.588221106 +0200
+++ /tmp/man.el	2016-04-02 13:28:07.580237516 +0200
@@ -1001,7 +1001,16 @@
       (error "No item under point")
     (man man-args)))
 
-(defmacro Man-start-calling (&rest body)
+(defun Man-buffer-or-window-width (buffer-or-window)
+  "Get width of window used after BUFFER-OR-WINDOW is displayed."
+  (if (windowp buffer-or-window)
+      (window-width buffer-or-window)
+    (save-window-excursion
+      (window-width (display-buffer buffer-or-window
+                                    ;; As used by `Man-notify-when-ready'.
+                                    'not-this-window)))))
+
+(defmacro Man-start-calling (buffer-or-window &rest body)
   "Start the man command in `body' after setting up the environment"
   `(let ((process-environment (copy-sequence process-environment))
 	;; The following is so Awk script gets \n intact
@@ -1040,7 +1049,7 @@
 			  ((and (integerp Man-width) (> Man-width 0))
 			   Man-width)
 			  (Man-width (frame-width))
-			  ((window-width))))))
+			  ((Man-buffer-or-window-width ,buffer-or-window))))))
     ;; 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).
@@ -1062,7 +1071,7 @@
 	(setq buffer-undo-list t)
 	(setq Man-original-frame (selected-frame))
 	(setq Man-arguments man-args))
-      (Man-start-calling
+      (Man-start-calling buffer
        (if (fboundp 'start-process)
 	    (set-process-sentinel
 	     (start-process manual-program buffer
@@ -1099,7 +1108,7 @@
 	(inhibit-read-only t)
 	(buffer-read-only nil))
      (erase-buffer)
-     (Man-start-calling
+     (Man-start-calling (frame-selected-window)
       (call-process shell-file-name nil (list (current-buffer) nil) nil
 		    shell-command-switch
 		    (format (Man-build-man-command) Man-arguments)))

Message #26 received at 23169 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Lluís <xscript <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 23169 <at> debbugs.gnu.org
Subject: Re: bug#23169: 24.5;
 Inconsistent text reflow in man pages depending on window
 configuration
Date: Sat, 02 Apr 2016 23:23:09 +0300

> Martin's "pretend" argument to display-buffer could be a way out of this
> conundrum. Also, here's a patch for an alternative fix.

I wonder why you are trying to patch an old version of man.el
instead of using the latest version where this problem is already fixed.

Message #29 received at 23169 <at> debbugs.gnu.org (full text, mbox):

From: Lluís <xscript <at> gmx.net>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 23169 <at> debbugs.gnu.org
Subject: Re: bug#23169: 24.5;
 Inconsistent text reflow in man pages depending on window
 configuration
Date: Sun, 03 Apr 2016 15:30:19 +0200

Juri Linkov writes:

>> Martin's "pretend" argument to display-buffer could be a way out of this
>> conundrum. Also, here's a patch for an alternative fix.

> I wonder why you are trying to patch an old version of man.el
> instead of using the latest version where this problem is already fixed.

The subject points to 24.5 (as generated by report-emacs-bug). I wasn't aware of
newer versions patching this; I can confirm eval'ing man.el from the emacs-25
branch works fine.


Thanks,
  Lluis

Message #32 received at 23169 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lluís <xscript <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 23169 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#23169: 24.5; Inconsistent text reflow in man pages depending
 on window configuration
Date: Sun, 29 Sep 2019 07:40:20 +0200

tags 23169 + fixed
close 23169
quit

Lluís <xscript <at> gmx.net> writes:

> Juri Linkov writes:
>
>>> Martin's "pretend" argument to display-buffer could be a way out of this
>>> conundrum. Also, here's a patch for an alternative fix.
>
>> I wonder why you are trying to patch an old version of man.el
>> instead of using the latest version where this problem is already fixed.
>
> The subject points to 24.5 (as generated by report-emacs-bug). I wasn't aware of
> newer versions patching this; I can confirm eval'ing man.el from the emacs-25
> branch works fine.

User reports above that this is fixed in Emacs 25.  I'm therefore
closing this bug.

Best regards,
Stefan Kangas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.