bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

[Lluís]

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

bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

[Eli Zaretskii]

> From: Lluís <xscript@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?

bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

[Lluís]

Eli Zaretskii writes:

>> From: Lluís <xscript@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

bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

[martin rudalics]

 > 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

bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

[Eli Zaretskii]

> From: Lluís <xscript@gmx.net>
> Cc: 23169@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.

bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

[Juri Linkov]

>> > 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.

bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

[Lluís]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

Eli Zaretskii writes:

>> From: Lluís <xscript@gmx.net>
>> Cc: 23169@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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: man.el.patch --]
[-- Type: text/x-diff, Size: 1934 bytes --]

--- /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)))

bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

[Juri Linkov]

> 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.

bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

[Lluís]

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

bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration

[Stefan Kangas]

tags 23169 + fixed
close 23169
quit

Lluís <xscript@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