* 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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.