bug#70213: Info-mode side window fit-window-to-buffer issue

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

With emacs -Q on 29, evaluate:

(setq display-buffer-alist
      '(((derived-mode . Info-mode)
         display-buffer-in-side-window
         (side . right)
         (window-width . fit-window-to-buffer))))

Then press C-h i

Expected: Info-mode buffer pops up in right side window.

Actual: Info-mode buffer pops up in full frame.

At this point, pressing C-h i once more does open a right side window.

I haven't been able to reproduce this this issue with any other mode.

Thanks!

Joseph

bug#70213: Info-mode side window fit-window-to-buffer issue

[Eli Zaretskii]

tags 70213 notabug
thanks

> Date: Fri, 05 Apr 2024 01:57:13 -0700
> From:  Joseph Turner via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> With emacs -Q on 29, evaluate:
> 
> (setq display-buffer-alist
>       '(((derived-mode . Info-mode)
>          display-buffer-in-side-window
>          (side . right)
>          (window-width . fit-window-to-buffer))))
> 
> Then press C-h i
> 
> Expected: Info-mode buffer pops up in right side window.
> 
> Actual: Info-mode buffer pops up in full frame.
> 
> At this point, pressing C-h i once more does open a right side window.
> 
> I haven't been able to reproduce this this issue with any other mode.

I'm not interested in fixing this: Info is not intended to be run in a
side window.  For starters, the text of an Info file is not meant to
be displayed in narrow windows, and will look ugly at best.

Don't do that!

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 70213 notabug
> thanks
>
>> Date: Fri, 05 Apr 2024 01:57:13 -0700
>> From:  Joseph Turner via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> With emacs -Q on 29, evaluate:
>>
>> (setq display-buffer-alist
>>       '(((derived-mode . Info-mode)
>>          display-buffer-in-side-window
>>          (side . right)
>>          (window-width . fit-window-to-buffer))))
>>
>> Then press C-h i
>>
>> Expected: Info-mode buffer pops up in right side window.
>>
>> Actual: Info-mode buffer pops up in full frame.
>>
>> At this point, pressing C-h i once more does open a right side window.
>>
>> I haven't been able to reproduce this this issue with any other mode.
>
> I'm not interested in fixing this: Info is not intended to be run in a
> side window.  For starters, the text of an Info file is not meant to
> be displayed in narrow windows, and will look ugly at best.
>
> Don't do that!

Okay, closing now.  What I had been doing is setting the side window with
to 80 columns, which is plenty of space for most Info files.

bug#70213: Info-mode side window fit-window-to-buffer issue

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Fri, 05 Apr 2024 08:04:28 -0700 Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> tags 70213 notabug
>> thanks
>>
>>> Date: Fri, 05 Apr 2024 01:57:13 -0700
>>> From:  Joseph Turner via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>
>>> With emacs -Q on 29, evaluate:
>>>
>>> (setq display-buffer-alist
>>>       '(((derived-mode . Info-mode)
>>>          display-buffer-in-side-window
>>>          (side . right)
>>>          (window-width . fit-window-to-buffer))))
>>>
>>> Then press C-h i
>>>
>>> Expected: Info-mode buffer pops up in right side window.
>>>
>>> Actual: Info-mode buffer pops up in full frame.
>>>
>>> At this point, pressing C-h i once more does open a right side window.
>>>
>>> I haven't been able to reproduce this this issue with any other mode.
>>
>> I'm not interested in fixing this: Info is not intended to be run in a
>> side window.  For starters, the text of an Info file is not meant to
>> be displayed in narrow windows, and will look ugly at best.
>>
>> Don't do that!
>
> Okay, closing now.  What I had been doing is setting the side window with
> to 80 columns, which is plenty of space for most Info files.

FWIW, I get the expected result with your recipe on master (GNU/Linux,
Gtk3; I don't have emacs-29 at hand to test).

Steve Berman

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Fri, 05 Apr 2024 08:04:28 -0700 Joseph Turner via "Bug reports for
> GNU Emacs, the Swiss army knife of text editors"
> <bug-gnu-emacs@gnu.org> wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> tags 70213 notabug
>>> thanks
>>>
>>>> Date: Fri, 05 Apr 2024 01:57:13 -0700
>>>> From:  Joseph Turner via "Bug reports for GNU Emacs,
>>>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>>
>>>> With emacs -Q on 29, evaluate:
>>>>
>>>> (setq display-buffer-alist
>>>>       '(((derived-mode . Info-mode)
>>>>          display-buffer-in-side-window
>>>>          (side . right)
>>>>          (window-width . fit-window-to-buffer))))
>>>>
>>>> Then press C-h i
>>>>
>>>> Expected: Info-mode buffer pops up in right side window.
>>>>
>>>> Actual: Info-mode buffer pops up in full frame.
>>>>
>>>> At this point, pressing C-h i once more does open a right side window.
>>>>
>>>> I haven't been able to reproduce this this issue with any other mode.
>>>
>>> I'm not interested in fixing this: Info is not intended to be run in a
>>> side window.  For starters, the text of an Info file is not meant to
>>> be displayed in narrow windows, and will look ugly at best.
>>>
>>> Don't do that!
>>
>> Okay, closing now.  What I had been doing is setting the side window with
>> to 80 columns, which is plenty of space for most Info files.
>
> FWIW, I get the expected result with your recipe on master (GNU/Linux,
> Gtk3; I don't have emacs-29 at hand to test).

According to the issue that Juri linked to (bug#68081), this issue was
resolved on master.  Was your Emacs build since January 6 (since
d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?

Thank you!

Joseph

bug#70213: Info-mode side window fit-window-to-buffer issue

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Fri, 05 Apr 2024 08:04:28 -0700 Joseph Turner via "Bug reports for
>> GNU Emacs, the Swiss army knife of text editors"
>> <bug-gnu-emacs@gnu.org> wrote:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> tags 70213 notabug
>>>> thanks
>>>>
>>>>> Date: Fri, 05 Apr 2024 01:57:13 -0700
>>>>> From:  Joseph Turner via "Bug reports for GNU Emacs,
>>>>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>>>
>>>>> With emacs -Q on 29, evaluate:
>>>>>
>>>>> (setq display-buffer-alist
>>>>>       '(((derived-mode . Info-mode)
>>>>>          display-buffer-in-side-window
>>>>>          (side . right)
>>>>>          (window-width . fit-window-to-buffer))))
>>>>>
>>>>> Then press C-h i
>>>>>
>>>>> Expected: Info-mode buffer pops up in right side window.
>>>>>
>>>>> Actual: Info-mode buffer pops up in full frame.
>>>>>
>>>>> At this point, pressing C-h i once more does open a right side window.
>>>>>
>>>>> I haven't been able to reproduce this this issue with any other mode.
>>>>
>>>> I'm not interested in fixing this: Info is not intended to be run in a
>>>> side window.  For starters, the text of an Info file is not meant to
>>>> be displayed in narrow windows, and will look ugly at best.
>>>>
>>>> Don't do that!
>>>
>>> Okay, closing now.  What I had been doing is setting the side window with
>>> to 80 columns, which is plenty of space for most Info files.
>>
>> FWIW, I get the expected result with your recipe on master (GNU/Linux,
>> Gtk3; I don't have emacs-29 at hand to test).
>
> According to the issue that Juri linked to (bug#68081), this issue was
> resolved on master.

Yes, I saw Juri's post after I sent mine; I had missed that bug report.

>                      Was your Emacs build since January 6 (since
> d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?

Yep, I'm currently at
09f381d70d8..: Michael Albinus 2024-03-31 Fix wildcard signals in dbusbind.c

Steve Berman

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Stephen Berman <stephen.berman@gmx.net> writes:

> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>> FWIW, I get the expected result with your recipe on master (GNU/Linux,
>>> Gtk3; I don't have emacs-29 at hand to test).
>>
>> According to the issue that Juri linked to (bug#68081), this issue was
>> resolved on master.
>
> Yes, I saw Juri's post after I sent mine; I had missed that bug report.
>
>>                      Was your Emacs build since January 6 (since
>> d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?
>
> Yep, I'm currently at
> 09f381d70d8..: Michael Albinus 2024-03-31 Fix wildcard signals in dbusbind.c

The attached patch fixes this issue, but more would need to be done for
fit-window-to-buffer to be a meaningful value in display-buffer-alist,
since navigating between info nodes doesn't cause the window to resize.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Display-buffer-after-ensuring-it-contains-text.patch --]
[-- Type: text/x-diff, Size: 2436 bytes --]

From f8a2584e3927c149eb2b008de5cb27fb148f08e1 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 5 Apr 2024 18:32:36 -0700
Subject: [PATCH] Display buffer after ensuring it contains text

* lisp/info.el (info-pop-to-buffer):

bug#70213
---
 lisp/info.el | 44 +++++++++++++++++++++-----------------------
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/lisp/info.el b/lisp/info.el
index 1e478cdbee9..fe134161af4 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -807,30 +807,28 @@ info-pop-to-buffer
 		  (get-buffer-create "*info*")))))
     (with-current-buffer buffer
       (unless (derived-mode-p 'Info-mode)
-	(Info-mode)))
+	(Info-mode))
+
+      (if file-or-node
+	  ;; If argument already contains parentheses, don't add another set
+	  ;; since the argument will then be parsed improperly.  This also
+	  ;; has the added benefit of allowing node names to be included
+	  ;; following the parenthesized filename.
+	  (Info-goto-node
+	   (if (and (stringp file-or-node) (string-match "(.*)" file-or-node))
+	       file-or-node
+             (concat "(" file-or-node ")")))
+	(if (and (zerop (buffer-size))
+		 (null Info-history))
+	    ;; If we just created the Info buffer, go to the directory.
+	    (Info-directory))))
+
+    (when-let ((window (display-buffer buffer
+			               (if other-window
+				           '(nil (inhibit-same-window . t))
+			                 '(display-buffer-same-window)))))
+      (select-window window))))
 
-    (let* ((window
-	    (display-buffer buffer
-			    (if other-window
-				'(nil (inhibit-same-window . t))
-			      '(display-buffer-same-window)))))
-      (with-current-buffer buffer
-	(if file-or-node
-	    ;; If argument already contains parentheses, don't add another set
-	    ;; since the argument will then be parsed improperly.  This also
-	    ;; has the added benefit of allowing node names to be included
-	    ;; following the parenthesized filename.
-	    (Info-goto-node
-	     (if (and (stringp file-or-node) (string-match "(.*)" file-or-node))
-		 file-or-node
-               (concat "(" file-or-node ")")))
-	  (if (and (zerop (buffer-size))
-		   (null Info-history))
-	      ;; If we just created the Info buffer, go to the directory.
-	      (Info-directory))))
-
-      (when window
-	(select-window window)))))
 
 ;;;###autoload (put 'info 'info-file (purecopy "emacs"))
 ;;;###autoload
-- 
2.41.0

bug#70213: Info-mode side window fit-window-to-buffer issue

[Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> more would need to be done for
> fit-window-to-buffer to be a meaningful value
> in display-buffer-alist, since navigating between 
> info nodes doesn't cause the window to resize.

(Caveat: I'm not following this thread.)

In case it helps, in info+.el I fit the
frame to the Info buffer when user option
`Info-fit-frame-flag' is non-nil and the
frame has only the Info window.

I do that in my versions of `Info-search'
and `Info-find-node-2'.  That's all that's
needed.

Likely the same two places would suffice
for what you're doing.  (But again, I'm
not following the thread - just guessing
what you're doing.)

(Dunno why something as general as
`display-buffer-alist' would need to be
involved, just to resize Info nodes.)

Hopefully you too will make the behavior
conditional on a user option.

HTH.

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Drew Adams <drew.adams@oracle.com> writes:

>> more would need to be done for
>> fit-window-to-buffer to be a meaningful value
>> in display-buffer-alist, since navigating between
>> info nodes doesn't cause the window to resize.
>
> (Caveat: I'm not following this thread.)
>
> In case it helps, in info+.el I fit the
> frame to the Info buffer when user option
> `Info-fit-frame-flag' is non-nil and the
> frame has only the Info window.
>
> I do that in my versions of `Info-search'
> and `Info-find-node-2'.  That's all that's
> needed.
>
> Likely the same two places would suffice
> for what you're doing.  (But again, I'm
> not following the thread - just guessing
> what you're doing.)
>
> (Dunno why something as general as
> `display-buffer-alist' would need to be
> involved, just to resize Info nodes.)
>
> Hopefully you too will make the behavior
> conditional on a user option.
>
> HTH.

Thanks!  Good to know.

I'm willing to leave the current behavior as-is.

bug#70213: Info-mode side window fit-window-to-buffer issue

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Fri, 05 Apr 2024 18:34:11 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>> FWIW, I get the expected result with your recipe on master (GNU/Linux,
>>>> Gtk3; I don't have emacs-29 at hand to test).
>>>
>>> According to the issue that Juri linked to (bug#68081), this issue was
>>> resolved on master.
>>
>> Yes, I saw Juri's post after I sent mine; I had missed that bug report.
>>
>>>                      Was your Emacs build since January 6 (since
>>> d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?
>>
>> Yep, I'm currently at
>> 09f381d70d8..: Michael Albinus 2024-03-31 Fix wildcard signals in dbusbind.c
>
> The attached patch fixes this issue, but more would need to be done for
> fit-window-to-buffer to be a meaningful value in display-buffer-alist,
> since navigating between info nodes doesn't cause the window to resize.

I'm confused: by "I get the expected result with your recipe on master"
I meant the Info buffer appears in the window on the right after one
`C-h i', and I confirmed that my build contains the January 6 fix.  Are
you saying that does not work for you and you need the patch you posted
instead?  (I haven't tried that patch.)

Steve Berman

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Fri, 05 Apr 2024 18:34:11 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner
>>> <joseph@breatheoutbreathe.in> wrote:
>>>
>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>> FWIW, I get the expected result with your recipe on master (GNU/Linux,
>>>>> Gtk3; I don't have emacs-29 at hand to test).
>>>>
>>>> According to the issue that Juri linked to (bug#68081), this issue was
>>>> resolved on master.
>>>
>>> Yes, I saw Juri's post after I sent mine; I had missed that bug report.
>>>
>>>>                      Was your Emacs build since January 6 (since
>>>> d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?
>>>
>>> Yep, I'm currently at
>>> 09f381d70d8..: Michael Albinus 2024-03-31 Fix wildcard signals in dbusbind.c
>>
>> The attached patch fixes this issue, but more would need to be done for
>> fit-window-to-buffer to be a meaningful value in display-buffer-alist,
>> since navigating between info nodes doesn't cause the window to resize.
>
> I'm confused: by "I get the expected result with your recipe on master"
> I meant the Info buffer appears in the window on the right after one
> `C-h i', and I confirmed that my build contains the January 6 fix.  Are
> you saying that does not work for you and you need the patch you posted
> instead?  (I haven't tried that patch.)

Sorry.  In my attempt to simplify the issue, I confused myself.

In emacs -Q on master after Jan 6 patch, eval this:

(progn
  (setq fit-window-to-buffer-horizontally t)

  (setq display-buffer-alist
        '(((derived-mode . Info-mode)
           display-buffer-in-side-window
           (side . right)
           (window-width . fit-window-to-buffer))
	  ((derived-mode . messages-buffer-mode)
           display-buffer-in-side-window
           (side . right)
           (window-width . fit-window-to-buffer)))))

First, to show the expected behavior with *Messages* buffer:

Press C-h e to open the *Messages* buffer.  It appears in a side
window on the right fit to the width of the buffer content.

Second, to show the unexpected behavior with *info* buffer:

Ensure no side window state is lying around:

(dolist (buf (list "*Messages*" "*info*"))
  (when (get-buffer buf)
    (kill-buffer buf)))

Press C-h i to open the *info* buffer.  It appears in a side
window on the right with `window-min-width' (default 10), but the
content of the *info* buffer is much wider than its window.

Press C-h i again for the *info* buffer to resize itself.

I would expect the *info* window to fit to the buffer contents
when it first appears.  The patch I sent earlier fixes this.

Thanks,

Joseph

bug#70213: Info-mode side window fit-window-to-buffer issue

[Juri Linkov]

> In emacs -Q on master after Jan 6 patch, eval this:

Maybe Martin could help to solve this problem (Cc-ed).

> (progn
>   (setq fit-window-to-buffer-horizontally t)
>
>   (setq display-buffer-alist
>         '(((derived-mode . Info-mode)
>            display-buffer-in-side-window
>            (side . right)
>            (window-width . fit-window-to-buffer))
> 	  ((derived-mode . messages-buffer-mode)
>            display-buffer-in-side-window
>            (side . right)
>            (window-width . fit-window-to-buffer)))))
>
> First, to show the expected behavior with *Messages* buffer:
>
> Press C-h e to open the *Messages* buffer.  It appears in a side
> window on the right fit to the width of the buffer content.
>
> Second, to show the unexpected behavior with *info* buffer:
>
> Ensure no side window state is lying around:
>
> (dolist (buf (list "*Messages*" "*info*"))
>   (when (get-buffer buf)
>     (kill-buffer buf)))
>
> Press C-h i to open the *info* buffer.  It appears in a side
> window on the right with `window-min-width' (default 10), but the
> content of the *info* buffer is much wider than its window.
>
> Press C-h i again for the *info* buffer to resize itself.
>
> I would expect the *info* window to fit to the buffer contents
> when it first appears.  The patch I sent earlier fixes this.

bug#70213: Info-mode side window fit-window-to-buffer issue

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 >> In emacs -Q on master after Jan 6 patch, eval this:
 >
 > Maybe Martin could help to solve this problem (Cc-ed).
 >
 >> (progn
 >>    (setq fit-window-to-buffer-horizontally t)
 >>
 >>    (setq display-buffer-alist
 >>          '(((derived-mode . Info-mode)
 >>             display-buffer-in-side-window
 >>             (side . right)
 >>             (window-width . fit-window-to-buffer))
 >> 	  ((derived-mode . messages-buffer-mode)
 >>             display-buffer-in-side-window
 >>             (side . right)
 >>             (window-width . fit-window-to-buffer)))))

At the time we call 'fit-window-to-buffer' the buffer is empty so we
show only 'window-min-width' columns.  Don't we have 'body-function' for
that?

 >> I would expect the *info* window to fit to the buffer contents
 >> when it first appears.  The patch I sent earlier fixes this.

That patch is

Display-buffer-after-ensuring-it-contains-text.patch

IIUC.  It already explains the problem in its name and does look good to
me.

martin

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics <rudalics@gmx.at> writes:

>>> In emacs -Q on master after Jan 6 patch, eval this:
>>
>> Maybe Martin could help to solve this problem (Cc-ed).
>>
>>> (progn
>>>    (setq fit-window-to-buffer-horizontally t)
>>>
>>>    (setq display-buffer-alist
>>>          '(((derived-mode . Info-mode)
>>>             display-buffer-in-side-window
>>>             (side . right)
>>>             (window-width . fit-window-to-buffer))
>>> 	  ((derived-mode . messages-buffer-mode)
>>>             display-buffer-in-side-window
>>>             (side . right)
>>>             (window-width . fit-window-to-buffer)))))
>
> At the time we call 'fit-window-to-buffer' the buffer is empty so we
> show only 'window-min-width' columns.  Don't we have 'body-function' for
> that?

Thanks for the review!  We have the same understanding of the issue.

What do you mean by 'body-function'?

>>> I would expect the *info* window to fit to the buffer contents
>>> when it first appears.  The patch I sent earlier fixes this.
>
> That patch is
>
> Display-buffer-after-ensuring-it-contains-text.patch

> IIUC.  It already explains the problem in its name and does look good to
> me.

Thanks for the review!  Stephen, Juri, Eli, WDYT?

Joseph

bug#70213: Info-mode side window fit-window-to-buffer issue

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sun, 07 Apr 2024 10:53:00 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> martin rudalics <rudalics@gmx.at> writes:
>
>>>> In emacs -Q on master after Jan 6 patch, eval this:
>>>
>>> Maybe Martin could help to solve this problem (Cc-ed).
>>>
>>>> (progn
>>>>    (setq fit-window-to-buffer-horizontally t)
>>>>
>>>>    (setq display-buffer-alist
>>>>          '(((derived-mode . Info-mode)
>>>>             display-buffer-in-side-window
>>>>             (side . right)
>>>>             (window-width . fit-window-to-buffer))
>>>> 	  ((derived-mode . messages-buffer-mode)
>>>>             display-buffer-in-side-window
>>>>             (side . right)
>>>>             (window-width . fit-window-to-buffer)))))
>>
>> At the time we call 'fit-window-to-buffer' the buffer is empty so we
>> show only 'window-min-width' columns.  Don't we have 'body-function' for
>> that?
>
> Thanks for the review!  We have the same understanding of the issue.
>
> What do you mean by 'body-function'?
>
>>>> I would expect the *info* window to fit to the buffer contents
>>>> when it first appears.  The patch I sent earlier fixes this.
>>
>> That patch is
>>
>> Display-buffer-after-ensuring-it-contains-text.patch
>
>> IIUC.  It already explains the problem in its name and does look good to
>> me.
>
> Thanks for the review!  Stephen, Juri, Eli, WDYT?

I agree that your patch is an improvement when
fit-window-to-buffer-horizontally is set to t.  However, as I noted
upthread, the resulting width of the right-side window is too small,
unlike when using the same setting of display-buffer-alist with
fit-window-to-buffer-horizontally set to nil, with which the setting of
display-buffer-alist works just as well without your patch.  So even
with your patch, there remains a problem.

Steve Berman

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Sun, 07 Apr 2024 10:53:00 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> martin rudalics <rudalics@gmx.at> writes:
>>
>>>>> In emacs -Q on master after Jan 6 patch, eval this:
>>>>
>>>> Maybe Martin could help to solve this problem (Cc-ed).
>>>>
>>>>> (progn
>>>>>    (setq fit-window-to-buffer-horizontally t)
>>>>>
>>>>>    (setq display-buffer-alist
>>>>>          '(((derived-mode . Info-mode)
>>>>>             display-buffer-in-side-window
>>>>>             (side . right)
>>>>>             (window-width . fit-window-to-buffer))
>>>>> 	  ((derived-mode . messages-buffer-mode)
>>>>>             display-buffer-in-side-window
>>>>>             (side . right)
>>>>>             (window-width . fit-window-to-buffer)))))
>>>
>>> At the time we call 'fit-window-to-buffer' the buffer is empty so we
>>> show only 'window-min-width' columns.  Don't we have 'body-function' for
>>> that?
>>
>> Thanks for the review!  We have the same understanding of the issue.
>>
>> What do you mean by 'body-function'?
>>
>>>>> I would expect the *info* window to fit to the buffer contents
>>>>> when it first appears.  The patch I sent earlier fixes this.
>>>
>>> That patch is
>>>
>>> Display-buffer-after-ensuring-it-contains-text.patch
>>
>>> IIUC.  It already explains the problem in its name and does look good to
>>> me.
>>
>> Thanks for the review!  Stephen, Juri, Eli, WDYT?
>
> I agree that your patch is an improvement when
> fit-window-to-buffer-horizontally is set to t.  However, as I noted
> upthread, the resulting width of the right-side window is too small,
> unlike when using the same setting of display-buffer-alist with
> fit-window-to-buffer-horizontally set to nil, with which the setting of
> display-buffer-alist works just as well without your patch.  So even
> with your patch, there remains a problem.

It turns out that it's necessary to set window-resize-pixelwise also, as
noted in (info "(elisp)Frame Layouts with Side Windows") .

In emacs -Q with the patch, the following snippet should the width of
the largest line, which on my machine is 74, the width of this line:

  In Emacs, you can click mouse button 2 on a menu item or cross reference

(progn
  (setq fit-window-to-buffer-horizontally t)
  (setq window-resize-pixelwise t)

  (setq display-buffer-alist
        '(((derived-mode . Info-mode)
           display-buffer-in-side-window
           (side . right)
           (window-width . fit-window-to-buffer))))

  (info)
  (window-width))

Joseph

bug#70213: Info-mode side window fit-window-to-buffer issue

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sun, 07 Apr 2024 16:11:07 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Sun, 07 Apr 2024 10:53:00 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> martin rudalics <rudalics@gmx.at> writes:
>>>
>>>>>> In emacs -Q on master after Jan 6 patch, eval this:
>>>>>
>>>>> Maybe Martin could help to solve this problem (Cc-ed).
>>>>>
>>>>>> (progn
>>>>>>    (setq fit-window-to-buffer-horizontally t)
>>>>>>
>>>>>>    (setq display-buffer-alist
>>>>>>          '(((derived-mode . Info-mode)
>>>>>>             display-buffer-in-side-window
>>>>>>             (side . right)
>>>>>>             (window-width . fit-window-to-buffer))
>>>>>> 	  ((derived-mode . messages-buffer-mode)
>>>>>>             display-buffer-in-side-window
>>>>>>             (side . right)
>>>>>>             (window-width . fit-window-to-buffer)))))
>>>>
>>>> At the time we call 'fit-window-to-buffer' the buffer is empty so we
>>>> show only 'window-min-width' columns.  Don't we have 'body-function' for
>>>> that?
>>>
>>> Thanks for the review!  We have the same understanding of the issue.
>>>
>>> What do you mean by 'body-function'?
>>>
>>>>>> I would expect the *info* window to fit to the buffer contents
>>>>>> when it first appears.  The patch I sent earlier fixes this.
>>>>
>>>> That patch is
>>>>
>>>> Display-buffer-after-ensuring-it-contains-text.patch
>>>
>>>> IIUC.  It already explains the problem in its name and does look good to
>>>> me.
>>>
>>> Thanks for the review!  Stephen, Juri, Eli, WDYT?
>>
>> I agree that your patch is an improvement when
>> fit-window-to-buffer-horizontally is set to t.  However, as I noted
>> upthread, the resulting width of the right-side window is too small,
>> unlike when using the same setting of display-buffer-alist with
>> fit-window-to-buffer-horizontally set to nil, with which the setting of
>> display-buffer-alist works just as well without your patch.  So even
>> with your patch, there remains a problem.
>
> It turns out that it's necessary to set window-resize-pixelwise also, as
> noted in (info "(elisp)Frame Layouts with Side Windows") .
>
> In emacs -Q with the patch, the following snippet should the width of
> the largest line, which on my machine is 74, the width of this line:

Yep, now I get that too (after widening the frame sufficiently, since
the standard default of 80 columns (which I have) is too narrow to fit
both windows with widths 6 and 74 plus the added scroll bar and
fringes).  So window-resize-pixelwise was the missing link, there's no
problem after all and your patch is good to go, as far as I'm concerned.
Thanks.

Steve Berman

>   In Emacs, you can click mouse button 2 on a menu item or cross reference
>
> (progn
>   (setq fit-window-to-buffer-horizontally t)
>   (setq window-resize-pixelwise t)
>
>   (setq display-buffer-alist
>         '(((derived-mode . Info-mode)
>            display-buffer-in-side-window
>            (side . right)
>            (window-width . fit-window-to-buffer))))
>
>   (info)
>   (window-width))

bug#70213: Info-mode side window fit-window-to-buffer issue

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > What do you mean by 'body-function'?

The doc-string of 'display-buffer' says

  `body-function' -- A function called with one argument - the
     displayed window.  It is called after the buffer is
     displayed, and before `window-height', `window-width'
     and `preserve-size' are applied.  The function is supposed
     to fill the window body with some contents that might depend
     on dimensions of the displayed window.

Using it in 'info-pop-to-buffer' would probably mean overkill though -
'Info-directory' doesn't care about the size of the window used for it.

martin

bug#70213: Info-mode side window fit-window-to-buffer issue

[Juri Linkov]

>> What do you mean by 'body-function'?
>
> The doc-string of 'display-buffer' says
>
>  `body-function' -- A function called with one argument - the
>     displayed window.  It is called after the buffer is
>     displayed, and before `window-height', `window-width'
>     and `preserve-size' are applied.  The function is supposed
>     to fill the window body with some contents that might depend
>     on dimensions of the displayed window.
>
> Using it in 'info-pop-to-buffer' would probably mean overkill though -
> 'Info-directory' doesn't care about the size of the window used for it.

Then maybe possible to swap the order of displaying and generating
the buffer in 'info-pop-to-buffer', and generate the contents of
the Info buffer before displaying it, like Joseph proposed?

bug#70213: Info-mode side window fit-window-to-buffer issue

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Then maybe possible to swap the order of displaying and generating
 > the buffer in 'info-pop-to-buffer', and generate the contents of
 > the Info buffer before displaying it, like Joseph proposed?

I think we should do that.  Displaying an empty buffer without providing
a 'body-function' is rarely a good idea IMO.

martin

bug#70213: Info-mode side window fit-window-to-buffer issue

[Eli Zaretskii]

> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: Juri Linkov <juri@linkov.net>, Stephen Berman <stephen.berman@gmx.net>,
>  70213@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 07 Apr 2024 10:53:00 -0700
> 
> Stephen, Juri, Eli, WDYT?

WDIT about what?

bug#70213: Info-mode side window fit-window-to-buffer issue

[Eli Zaretskii]

> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Tue, 09 Apr 2024 09:38:40 -0700
> 
> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
> >> Cc: Juri Linkov <juri@linkov.net>, Stephen Berman <stephen.berman@gmx.net>,
> >>  70213@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> >> Date: Sun, 07 Apr 2024 10:53:00 -0700
> >>
> >> Stephen, Juri, Eli, WDYT?
> >
> > WDIT about what?
> 
> IIUC, Juri, Martin, and Stephen all support installing this patch.

I'd like to hear from Martin that he agrees with this patch.  AFAIU,
the agreement about what is the problem and how best to fix it was
just one message ago, quite a few messages after your question.

(And why personal email just to me?  I assume it was a mistake.)

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Tue, 09 Apr 2024 09:38:40 -0700
>>
>> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> >> Cc: Juri Linkov <juri@linkov.net>, Stephen Berman <stephen.berman@gmx.net>,
>> >>  70213@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>> >> Date: Sun, 07 Apr 2024 10:53:00 -0700
>> >>
>> >> Stephen, Juri, Eli, WDYT?
>> >
>> > WDIT about what?
>>
>> IIUC, Juri, Martin, and Stephen all support installing this patch.
>
> I'd like to hear from Martin that he agrees with this patch.  AFAIU,
> the agreement about what is the problem and how best to fix it was
> just one message ago, quite a few messages after your question.
>
> (And why personal email just to me?  I assume it was a mistake.)

Yes, that was a mistake.  The mu4e keybinding for wide-reply changed in
the last update, and I hadn't adjusted yet.

Thanks!

Joseph

bug#70213: Info-mode side window fit-window-to-buffer issue

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > I'd like to hear from Martin that he agrees with this patch.

I agree.  But I'd like to hear Juri's opinion once more, too.

martin

bug#70213: Info-mode side window fit-window-to-buffer issue

[Juri Linkov]

>> I'd like to hear from Martin that he agrees with this patch.
>
> I agree.  But I'd like to hear Juri's opinion once more, too.

If generating the Info buffer doesn't depend on some properties
of the displayed window such as window dimensions, etc. then
it should be fine to generate an Info buffer before displaying it.
And I don't remember any such features that could fail in
a non-displayed Info buffer.

bug#70213: Info-mode side window fit-window-to-buffer issue

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > If generating the Info buffer doesn't depend on some properties
 > of the displayed window such as window dimensions, etc.

That's what I had in mind.  One day people might want to create info
buffers on-the-fly taking into account pre-existing window sizes.

 > then
 > it should be fine to generate an Info buffer before displaying it.
 > And I don't remember any such features that could fail in
 > a non-displayed Info buffer.

Neither do I.

martin

bug#70213: Info-mode side window fit-window-to-buffer issue

[Juri Linkov]

close 70213 30.0.50
thanks

>> If generating the Info buffer doesn't depend on some properties
>> of the displayed window such as window dimensions, etc.
>
> That's what I had in mind.  One day people might want to create info
> buffers on-the-fly taking into account pre-existing window sizes.

That day people will also add on-the-fly refilling of Info buffers.

>> then
>> it should be fine to generate an Info buffer before displaying it.
>> And I don't remember any such features that could fail in
>> a non-displayed Info buffer.
>
> Neither do I.

Ok, so now pushed Joseph's patch, and closed.

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@linkov.net> writes:

> close 70213 30.0.50
> thanks

[...]

> Ok, so now pushed Joseph's patch, and closed.

Thank you all for your careful review :)

Joseph

bug#70213: Info-mode side window fit-window-to-buffer issue

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sat, 06 Apr 2024 10:19:20 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Fri, 05 Apr 2024 18:34:11 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>
>>>> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner
>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>
>>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>>> FWIW, I get the expected result with your recipe on master (GNU/Linux,
>>>>>> Gtk3; I don't have emacs-29 at hand to test).
>>>>>
>>>>> According to the issue that Juri linked to (bug#68081), this issue was
>>>>> resolved on master.
>>>>
>>>> Yes, I saw Juri's post after I sent mine; I had missed that bug report.
>>>>
>>>>>                      Was your Emacs build since January 6 (since
>>>>> d3a4fe5694f7bd1a09546d67d2cddc0f444d41ca )?
>>>>
>>>> Yep, I'm currently at
>>>> 09f381d70d8..: Michael Albinus 2024-03-31 Fix wildcard signals in dbusbind.c
>>>
>>> The attached patch fixes this issue, but more would need to be done for
>>> fit-window-to-buffer to be a meaningful value in display-buffer-alist,
>>> since navigating between info nodes doesn't cause the window to resize.
>>
>> I'm confused: by "I get the expected result with your recipe on master"
>> I meant the Info buffer appears in the window on the right after one
>> `C-h i', and I confirmed that my build contains the January 6 fix.  Are
>> you saying that does not work for you and you need the patch you posted
>> instead?  (I haven't tried that patch.)
>
> Sorry.  In my attempt to simplify the issue, I confused myself.
>
> In emacs -Q on master after Jan 6 patch, eval this:
>
> (progn
>   (setq fit-window-to-buffer-horizontally t)
>
>   (setq display-buffer-alist
>         '(((derived-mode . Info-mode)
>            display-buffer-in-side-window
>            (side . right)
>            (window-width . fit-window-to-buffer))
> 	  ((derived-mode . messages-buffer-mode)
>            display-buffer-in-side-window
>            (side . right)
>            (window-width . fit-window-to-buffer)))))
>
> First, to show the expected behavior with *Messages* buffer:
>
> Press C-h e to open the *Messages* buffer.  It appears in a side
> window on the right fit to the width of the buffer content.
>
> Second, to show the unexpected behavior with *info* buffer:
>
> Ensure no side window state is lying around:
>
> (dolist (buf (list "*Messages*" "*info*"))
>   (when (get-buffer buf)
>     (kill-buffer buf)))
>
> Press C-h i to open the *info* buffer.  It appears in a side
> window on the right with `window-min-width' (default 10), but the
> content of the *info* buffer is much wider than its window.
>
> Press C-h i again for the *info* buffer to resize itself.
>
> I would expect the *info* window to fit to the buffer contents
> when it first appears.  The patch I sent earlier fixes this.

Ah, ok.  I somehow overlooked the fit-window-to-buffer part in your OP,
although it is in the bug Subject line -- though with my post-Jan 6
build from master, that's only problematic with
fit-window-to-buffer-horizontally set to t, as in your above recipe.
But with fit-window-to-buffer-horizontally set to t, I see that the
window displaying *info* is not quite fitted to the buffer (e.g. in the
initial dir node the line "In Emacs, you can click mouse button 2 on a
menu item or cross reference" wraps after the third "e" in "reference"
(column 70)), even if the frame is wide enough to display the entire
buffer.  I see this both with and without your patch; but with
fit-window-to-buffer-horizontally set to nil, then there is no line
wrapping (as long as the frame is wide enough).  This seems to be a bug
in the use of fit-window-to-buffer-horizontally.

Steve Berman

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> Ah, ok.  I somehow overlooked the fit-window-to-buffer part in your OP,
> although it is in the bug Subject line -- though with my post-Jan 6
> build from master, that's only problematic with
> fit-window-to-buffer-horizontally set to t, as in your above recipe.
> But with fit-window-to-buffer-horizontally set to t, I see that the
> window displaying *info* is not quite fitted to the buffer (e.g. in the
> initial dir node the line "In Emacs, you can click mouse button 2 on a
> menu item or cross reference" wraps after the third "e" in "reference"
> (column 70)), even if the frame is wide enough to display the entire
> buffer.  I see this both with and without your patch; but with
> fit-window-to-buffer-horizontally set to nil, then there is no line
> wrapping (as long as the frame is wide enough).  This seems to be a bug
> in the use of fit-window-to-buffer-horizontally.

Thank you for being gracious about my confusing report :)

On my machine, the following snippet:

(progn
  (setq fit-window-to-buffer-horizontally t)

  (setq display-buffer-alist
        '(((derived-mode . Info-mode)
           display-buffer-in-side-window
           (side . right)
           (window-width . fit-window-to-buffer))))

  (info)
  (window-width))

without the patch evaluates to 6

with the patch evaluates to 71

What happens on your machine?

Joseph

bug#70213: Info-mode side window fit-window-to-buffer issue

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Ah, ok.  I somehow overlooked the fit-window-to-buffer part in your OP,
>> although it is in the bug Subject line -- though with my post-Jan 6
>> build from master, that's only problematic with
>> fit-window-to-buffer-horizontally set to t, as in your above recipe.
>> But with fit-window-to-buffer-horizontally set to t, I see that the
>> window displaying *info* is not quite fitted to the buffer (e.g. in the
>> initial dir node the line "In Emacs, you can click mouse button 2 on a
>> menu item or cross reference" wraps after the third "e" in "reference"
>> (column 70)), even if the frame is wide enough to display the entire
>> buffer.  I see this both with and without your patch; but with
>> fit-window-to-buffer-horizontally set to nil, then there is no line
>> wrapping (as long as the frame is wide enough).  This seems to be a bug
>> in the use of fit-window-to-buffer-horizontally.
>
> Thank you for being gracious about my confusing report :)
>
> On my machine, the following snippet:
>
> (progn
>   (setq fit-window-to-buffer-horizontally t)
>
>   (setq display-buffer-alist
>         '(((derived-mode . Info-mode)
>            display-buffer-in-side-window
>            (side . right)
>            (window-width . fit-window-to-buffer))))
>
>   (info)
>   (window-width))
>
> without the patch evaluates to 6
>
> with the patch evaluates to 71
>
> What happens on your machine?

without the patch: 6
with the patch: 70

For an unsplit window, (window-width) returns 80 (with emacs -Q); does
it also for you?  I'm building on GNU/Linux with Gtk3.

Steve Berman

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> On my machine, the following snippet:
>>
>> (progn
>>   (setq fit-window-to-buffer-horizontally t)
>>
>>   (setq display-buffer-alist
>>         '(((derived-mode . Info-mode)
>>            display-buffer-in-side-window
>>            (side . right)
>>            (window-width . fit-window-to-buffer))))
>>
>>   (info)
>>   (window-width))
>>
>> without the patch evaluates to 6
>>
>> with the patch evaluates to 71
>>
>> What happens on your machine?
>
> without the patch: 6
> with the patch: 70

This indicates that the patch fixes the bug on your machine also.  Right?

> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
> it also for you?  I'm building on GNU/Linux with Gtk3.

Sorry, an unsplit window where?  Please clarify the instructions :)

Thanks!

Joseph

bug#70213: Info-mode side window fit-window-to-buffer issue

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> On my machine, the following snippet:
>>>
>>> (progn
>>>   (setq fit-window-to-buffer-horizontally t)
>>>
>>>   (setq display-buffer-alist
>>>         '(((derived-mode . Info-mode)
>>>            display-buffer-in-side-window
>>>            (side . right)
>>>            (window-width . fit-window-to-buffer))))
>>>
>>>   (info)
>>>   (window-width))
>>>
>>> without the patch evaluates to 6
>>>
>>> with the patch evaluates to 71
>>>
>>> What happens on your machine?
>>
>> without the patch: 6
>> with the patch: 70
>
> This indicates that the patch fixes the bug on your machine also.  Right?
>
>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>> it also for you?  I'm building on GNU/Linux with Gtk3.
>
> Sorry, an unsplit window where?  Please clarify the instructions :)
>
> Thanks!

Sorry for being unclear; what I meant is the return value of
(window-width) evaluated immediately after starting emacs -Q, so the
frame consists of a single window.

Steve Berman

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>> <joseph@breatheoutbreathe.in> wrote:
>>>
>>>> On my machine, the following snippet:
>>>>
>>>> (progn
>>>>   (setq fit-window-to-buffer-horizontally t)
>>>>
>>>>   (setq display-buffer-alist
>>>>         '(((derived-mode . Info-mode)
>>>>            display-buffer-in-side-window
>>>>            (side . right)
>>>>            (window-width . fit-window-to-buffer))))
>>>>
>>>>   (info)
>>>>   (window-width))
>>>>
>>>> without the patch evaluates to 6
>>>>
>>>> with the patch evaluates to 71
>>>>
>>>> What happens on your machine?
>>>
>>> without the patch: 6
>>> with the patch: 70
>>
>> This indicates that the patch fixes the bug on your machine also.  Right?
>>
>>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>>> it also for you?  I'm building on GNU/Linux with Gtk3.
>>
>> Sorry, an unsplit window where?  Please clarify the instructions :)
>>
>> Thanks!
>
> Sorry for being unclear; what I meant is the return value of
> (window-width) evaluated immediately after starting emacs -Q, so the
> frame consists of a single window.

138 on my machine.

bug#70213: Info-mode side window fit-window-to-buffer issue

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>
>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>
>>>>> On my machine, the following snippet:
>>>>>
>>>>> (progn
>>>>>   (setq fit-window-to-buffer-horizontally t)
>>>>>
>>>>>   (setq display-buffer-alist
>>>>>         '(((derived-mode . Info-mode)
>>>>>            display-buffer-in-side-window
>>>>>            (side . right)
>>>>>            (window-width . fit-window-to-buffer))))
>>>>>
>>>>>   (info)
>>>>>   (window-width))
>>>>>
>>>>> without the patch evaluates to 6
>>>>>
>>>>> with the patch evaluates to 71
>>>>>
>>>>> What happens on your machine?
>>>>
>>>> without the patch: 6
>>>> with the patch: 70
>>>
>>> This indicates that the patch fixes the bug on your machine also.  Right?
>>>
>>>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>>>> it also for you?  I'm building on GNU/Linux with Gtk3.
>>>
>>> Sorry, an unsplit window where?  Please clarify the instructions :)
>>>
>>> Thanks!
>>
>> Sorry for being unclear; what I meant is the return value of
>> (window-width) evaluated immediately after starting emacs -Q, so the
>> frame consists of a single window.
>
> 138 on my machine.

I've never heard of that for -Q.  I though 80, which is what I get, was
standard, at least under X, and that's what the Emacs user manual says
(info "(emacs) Window Size X"): "The default frame width is 80
characters and the default height is between 35 and 40 lines, depending
on the OS and the window manager."  What graphical display system are
you using?

Steve Berman

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>>> <joseph@breatheoutbreathe.in> wrote:
>>>
>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>
>>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>>
>>>>>> On my machine, the following snippet:
>>>>>>
>>>>>> (progn
>>>>>>   (setq fit-window-to-buffer-horizontally t)
>>>>>>
>>>>>>   (setq display-buffer-alist
>>>>>>         '(((derived-mode . Info-mode)
>>>>>>            display-buffer-in-side-window
>>>>>>            (side . right)
>>>>>>            (window-width . fit-window-to-buffer))))
>>>>>>
>>>>>>   (info)
>>>>>>   (window-width))
>>>>>>
>>>>>> without the patch evaluates to 6
>>>>>>
>>>>>> with the patch evaluates to 71
>>>>>>
>>>>>> What happens on your machine?
>>>>>
>>>>> without the patch: 6
>>>>> with the patch: 70
>>>>
>>>> This indicates that the patch fixes the bug on your machine also.  Right?
>>>>
>>>>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>>>>> it also for you?  I'm building on GNU/Linux with Gtk3.
>>>>
>>>> Sorry, an unsplit window where?  Please clarify the instructions :)
>>>>
>>>> Thanks!
>>>
>>> Sorry for being unclear; what I meant is the return value of
>>> (window-width) evaluated immediately after starting emacs -Q, so the
>>> frame consists of a single window.
>>
>> 138 on my machine.
>
> I've never heard of that for -Q.  I though 80, which is what I get, was
> standard, at least under X, and that's what the Emacs user manual says
> (info "(emacs) Window Size X"): "The default frame width is 80
> characters and the default height is between 35 and 40 lines, depending
> on the OS and the window manager."  What graphical display system are
> you using?

I am using EXWM, and I ran emacs -Q as a subprocess inside of the main
Emacs process.  The emacs -Q instance ended up being full screen.

Joseph

bug#70213: Info-mode side window fit-window-to-buffer issue

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sun, 07 Apr 2024 15:13:07 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner
>> <joseph@breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>
>>>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>
>>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>>
>>>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>>>
>>>>>>> On my machine, the following snippet:
>>>>>>>
>>>>>>> (progn
>>>>>>>   (setq fit-window-to-buffer-horizontally t)
>>>>>>>
>>>>>>>   (setq display-buffer-alist
>>>>>>>         '(((derived-mode . Info-mode)
>>>>>>>            display-buffer-in-side-window
>>>>>>>            (side . right)
>>>>>>>            (window-width . fit-window-to-buffer))))
>>>>>>>
>>>>>>>   (info)
>>>>>>>   (window-width))
>>>>>>>
>>>>>>> without the patch evaluates to 6
>>>>>>>
>>>>>>> with the patch evaluates to 71
>>>>>>>
>>>>>>> What happens on your machine?
>>>>>>
>>>>>> without the patch: 6
>>>>>> with the patch: 70
>>>>>
>>>>> This indicates that the patch fixes the bug on your machine also.  Right?
>>>>>
>>>>>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>>>>>> it also for you?  I'm building on GNU/Linux with Gtk3.
>>>>>
>>>>> Sorry, an unsplit window where?  Please clarify the instructions :)
>>>>>
>>>>> Thanks!
>>>>
>>>> Sorry for being unclear; what I meant is the return value of
>>>> (window-width) evaluated immediately after starting emacs -Q, so the
>>>> frame consists of a single window.
>>>
>>> 138 on my machine.
>>
>> I've never heard of that for -Q.  I though 80, which is what I get, was
>> standard, at least under X, and that's what the Emacs user manual says
>> (info "(emacs) Window Size X"): "The default frame width is 80
>> characters and the default height is between 35 and 40 lines, depending
>> on the OS and the window manager."  What graphical display system are
>> you using?
>
> I am using EXWM, and I ran emacs -Q as a subprocess inside of the main
> Emacs process.  The emacs -Q instance ended up being full screen.

Ah, ok, so that overrides the Emacs default frame parameters for X.  So
I guess that's why you get different results with
fit-window-to-buffer-horizontally set to t than I do.

Steve Berman

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Sun, 07 Apr 2024 15:13:07 -0700 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner
>>> <joseph@breatheoutbreathe.in> wrote:
>>>
>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>
>>>>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>>
>>>>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>>>>
>>>>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>>>>> <joseph@breatheoutbreathe.in> wrote:
>>>>>>>
>>>>>>>> On my machine, the following snippet:
>>>>>>>>
>>>>>>>> (progn
>>>>>>>>   (setq fit-window-to-buffer-horizontally t)
>>>>>>>>
>>>>>>>>   (setq display-buffer-alist
>>>>>>>>         '(((derived-mode . Info-mode)
>>>>>>>>            display-buffer-in-side-window
>>>>>>>>            (side . right)
>>>>>>>>            (window-width . fit-window-to-buffer))))
>>>>>>>>
>>>>>>>>   (info)
>>>>>>>>   (window-width))
>>>>>>>>
>>>>>>>> without the patch evaluates to 6
>>>>>>>>
>>>>>>>> with the patch evaluates to 71
>>>>>>>>
>>>>>>>> What happens on your machine?
>>>>>>>
>>>>>>> without the patch: 6
>>>>>>> with the patch: 70
>>>>>>
>>>>>> This indicates that the patch fixes the bug on your machine also.  Right?
>>>>>>
>>>>>>> For an unsplit window, (window-width) returns 80 (with emacs -Q); does
>>>>>>> it also for you?  I'm building on GNU/Linux with Gtk3.
>>>>>>
>>>>>> Sorry, an unsplit window where?  Please clarify the instructions :)
>>>>>>
>>>>>> Thanks!
>>>>>
>>>>> Sorry for being unclear; what I meant is the return value of
>>>>> (window-width) evaluated immediately after starting emacs -Q, so the
>>>>> frame consists of a single window.
>>>>
>>>> 138 on my machine.
>>>
>>> I've never heard of that for -Q.  I though 80, which is what I get, was
>>> standard, at least under X, and that's what the Emacs user manual says
>>> (info "(emacs) Window Size X"): "The default frame width is 80
>>> characters and the default height is between 35 and 40 lines, depending
>>> on the OS and the window manager."  What graphical display system are
>>> you using?
>>
>> I am using EXWM, and I ran emacs -Q as a subprocess inside of the main
>> Emacs process.  The emacs -Q instance ended up being full screen.
>
> Ah, ok, so that overrides the Emacs default frame parameters for X.  So
> I guess that's why you get different results with
> fit-window-to-buffer-horizontally set to t than I do.

👍

bug#70213: Info-mode side window fit-window-to-buffer issue

[Juri Linkov]

> With emacs -Q on 29, evaluate:
>
> (setq display-buffer-alist
>       '(((derived-mode . Info-mode)
>          display-buffer-in-side-window
>          (side . right)
>          (window-width . fit-window-to-buffer))))

This is already fixed in Emacs 30 via bug#68081.

bug#70213: Info-mode side window fit-window-to-buffer issue

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@linkov.net> writes:

>> With emacs -Q on 29, evaluate:
>>
>> (setq display-buffer-alist
>>       '(((derived-mode . Info-mode)
>>          display-buffer-in-side-window
>>          (side . right)
>>          (window-width . fit-window-to-buffer))))
>
> This is already fixed in Emacs 30 via bug#68081.

Thank you very much for this reference!!

Joseph