* bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration
@ 2016-03-31 13:15 Lluís
2016-03-31 16:48 ` Eli Zaretskii
2019-09-29 5:40 ` Stefan Kangas
0 siblings, 2 replies; 10+ messages in thread
From: Lluís @ 2016-03-31 13:15 UTC (permalink / raw)
To: 23169
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration
2016-03-31 13:15 bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration Lluís
@ 2016-03-31 16:48 ` Eli Zaretskii
2016-04-01 15:13 ` Lluís
2019-09-29 5:40 ` Stefan Kangas
1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2016-03-31 16:48 UTC (permalink / raw)
To: Lluís; +Cc: 23169
> 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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration
2016-03-31 16:48 ` Eli Zaretskii
@ 2016-04-01 15:13 ` Lluís
2016-04-01 16:20 ` martin rudalics
2016-04-01 17:40 ` Eli Zaretskii
0 siblings, 2 replies; 10+ messages in thread
From: Lluís @ 2016-04-01 15:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 23169
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration
2016-04-01 15:13 ` Lluís
@ 2016-04-01 16:20 ` martin rudalics
2016-04-01 17:40 ` Eli Zaretskii
1 sibling, 0 replies; 10+ messages in thread
From: martin rudalics @ 2016-04-01 16:20 UTC (permalink / raw)
To: Lluís, Eli Zaretskii; +Cc: 23169
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration
2016-04-01 15:13 ` Lluís
2016-04-01 16:20 ` martin rudalics
@ 2016-04-01 17:40 ` Eli Zaretskii
2016-04-01 19:51 ` Juri Linkov
2016-04-02 11:30 ` Lluís
1 sibling, 2 replies; 10+ messages in thread
From: Eli Zaretskii @ 2016-04-01 17:40 UTC (permalink / raw)
To: Lluís; +Cc: 23169
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration
2016-04-01 17:40 ` Eli Zaretskii
@ 2016-04-01 19:51 ` Juri Linkov
2016-04-02 11:30 ` Lluís
1 sibling, 0 replies; 10+ messages in thread
From: Juri Linkov @ 2016-04-01 19:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 23169, Lluís
>> > 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration
2016-04-01 17:40 ` Eli Zaretskii
2016-04-01 19:51 ` Juri Linkov
@ 2016-04-02 11:30 ` Lluís
2016-04-02 20:23 ` Juri Linkov
1 sibling, 1 reply; 10+ messages in thread
From: Lluís @ 2016-04-02 11:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 23169
[-- 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)))
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration
2016-04-02 11:30 ` Lluís
@ 2016-04-02 20:23 ` Juri Linkov
2016-04-03 13:30 ` Lluís
0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2016-04-02 20:23 UTC (permalink / raw)
To: Lluís; +Cc: 23169
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration
2016-04-02 20:23 ` Juri Linkov
@ 2016-04-03 13:30 ` Lluís
0 siblings, 0 replies; 10+ messages in thread
From: Lluís @ 2016-04-03 13:30 UTC (permalink / raw)
To: Juri Linkov; +Cc: 23169
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration
2016-03-31 13:15 bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration Lluís
2016-03-31 16:48 ` Eli Zaretskii
@ 2019-09-29 5:40 ` Stefan Kangas
1 sibling, 0 replies; 10+ messages in thread
From: Stefan Kangas @ 2019-09-29 5:40 UTC (permalink / raw)
To: Lluís; +Cc: 23169, Juri Linkov
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-09-29 5:40 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-31 13:15 bug#23169: 24.5; Inconsistent text reflow in man pages depending on window configuration Lluís
2016-03-31 16:48 ` Eli Zaretskii
2016-04-01 15:13 ` Lluís
2016-04-01 16:20 ` martin rudalics
2016-04-01 17:40 ` Eli Zaretskii
2016-04-01 19:51 ` Juri Linkov
2016-04-02 11:30 ` Lluís
2016-04-02 20:23 ` Juri Linkov
2016-04-03 13:30 ` Lluís
2019-09-29 5:40 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).