GNU bug report logs - #70213
Info-mode side window fit-window-to-buffer issue

Previous Next

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

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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Emacs Bugs Mailing List <bug-gnu-emacs <at> gnu.org>
Subject: Info-mode side window fit-window-to-buffer issue
Date: Fri, 05 Apr 2024 01:57:13 -0700

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Fri, 05 Apr 2024 15:30:43 +0300

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 <at> 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!

Message #15 received at 70213-done <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70213-done <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Fri, 05 Apr 2024 08:04:28 -0700

Eli Zaretskii <eliz <at> 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 <at> 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.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: 70213 <at> debbugs.gnu.org
Cc: joseph <at> breatheoutbreathe.in
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Fri, 05 Apr 2024 17:33:44 +0200

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 <at> gnu.org> wrote:

> Eli Zaretskii <eliz <at> 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 <at> 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

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

From: Juri Linkov <juri <at> linkov.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Fri, 05 Apr 2024 19:09:49 +0300

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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Fri, 05 Apr 2024 14:57:15 -0700

Juri Linkov <juri <at> 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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Fri, 05 Apr 2024 14:58:27 -0700

Stephen Berman <stephen.berman <at> 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 <at> gnu.org> wrote:
>
>> Eli Zaretskii <eliz <at> 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 <at> 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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sat, 06 Apr 2024 00:21:41 +0200

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

> Stephen Berman <stephen.berman <at> 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 <at> gnu.org> wrote:
>>
>>> Eli Zaretskii <eliz <at> 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 <at> 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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Fri, 05 Apr 2024 18:34:11 -0700

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

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

> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner <joseph <at> breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman <at> 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.

[0001-Display-buffer-after-ensuring-it-contains-text.patch (text/x-diff, attachment)]

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>, Stephen Berman
 <stephen.berman <at> gmx.net>
Cc: "70213 <at> debbugs.gnu.org" <70213 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#70213: Info-mode side window
 fit-window-to-buffer issue
Date: Sat, 6 Apr 2024 01:55:18 +0000

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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Stephen Berman <stephen.berman <at> gmx.net>,
 "70213 <at> debbugs.gnu.org" <70213 <at> debbugs.gnu.org>
Subject: Re: [External] : bug#70213: Info-mode side window
 fit-window-to-buffer issue
Date: Fri, 05 Apr 2024 19:36:34 -0700

Drew Adams <drew.adams <at> 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.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sat, 06 Apr 2024 13:39:28 +0200

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

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner
>> <joseph <at> breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman <at> 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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sat, 06 Apr 2024 10:19:20 -0700

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

> On Fri, 05 Apr 2024 18:34:11 -0700 Joseph Turner <joseph <at> breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner
>>> <joseph <at> breatheoutbreathe.in> wrote:
>>>
>>>> Stephen Berman <stephen.berman <at> 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

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

From: Juri Linkov <juri <at> linkov.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: martin rudalics <rudalics <at> gmx.at>, Stephen Berman <stephen.berman <at> gmx.net>,
 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sat, 06 Apr 2024 21:39:14 +0300

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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sat, 06 Apr 2024 21:19:31 +0200

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

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Fri, 05 Apr 2024 18:34:11 -0700 Joseph Turner
>> <joseph <at> breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>
>>>> On Fri, 05 Apr 2024 14:58:27 -0700 Joseph Turner
>>>> <joseph <at> breatheoutbreathe.in> wrote:
>>>>
>>>>> Stephen Berman <stephen.berman <at> 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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sat, 06 Apr 2024 18:59:45 -0700

Stephen Berman <stephen.berman <at> 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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 7 Apr 2024 10:52:23 +0200

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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 07 Apr 2024 11:30:52 +0200

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

> Stephen Berman <stephen.berman <at> 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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 07 Apr 2024 10:47:58 -0700

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

> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner <joseph <at> 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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stephen Berman <stephen.berman <at> gmx.net>,
 70213 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 07 Apr 2024 10:53:00 -0700

martin rudalics <rudalics <at> 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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 07 Apr 2024 21:29:49 +0200

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

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>> <joseph <at> 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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 70213 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 07 Apr 2024 21:29:59 +0200

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

> martin rudalics <rudalics <at> 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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 07 Apr 2024 13:07:06 -0700

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

> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner <joseph <at> breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>> <joseph <at> 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.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 07 Apr 2024 22:51:49 +0200

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

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>> <joseph <at> breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>
>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>> <joseph <at> 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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 07 Apr 2024 15:13:07 -0700

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

> On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner <joseph <at> breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>>> <joseph <at> breatheoutbreathe.in> wrote:
>>>
>>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>>
>>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>>> <joseph <at> 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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Mon, 08 Apr 2024 00:35:17 +0200

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

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner
>> <joseph <at> breatheoutbreathe.in> wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>
>>>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>>>> <joseph <at> breatheoutbreathe.in> wrote:
>>>>
>>>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>>>
>>>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>>>> <joseph <at> 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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 07 Apr 2024 16:06:57 -0700

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

> On Sun, 07 Apr 2024 15:13:07 -0700 Joseph Turner <joseph <at> breatheoutbreathe.in> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> On Sun, 07 Apr 2024 13:07:06 -0700 Joseph Turner
>>> <joseph <at> breatheoutbreathe.in> wrote:
>>>
>>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>>
>>>>> On Sun, 07 Apr 2024 10:47:58 -0700 Joseph Turner
>>>>> <joseph <at> breatheoutbreathe.in> wrote:
>>>>>
>>>>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>>>>
>>>>>>> On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner
>>>>>>> <joseph <at> 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.

👍

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 70213 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Sun, 07 Apr 2024 16:11:07 -0700

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

> On Sun, 07 Apr 2024 10:53:00 -0700 Joseph Turner <joseph <at> breatheoutbreathe.in> wrote:
>
>> martin rudalics <rudalics <at> 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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 70213 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Mon, 08 Apr 2024 09:56:25 +0200

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

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Sun, 07 Apr 2024 10:53:00 -0700 Joseph Turner
>> <joseph <at> breatheoutbreathe.in> wrote:
>>
>>> martin rudalics <rudalics <at> 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))

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

From: martin rudalics <rudalics <at> gmx.at>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stephen Berman <stephen.berman <at> gmx.net>,
 70213 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Mon, 8 Apr 2024 11:08:03 +0200

> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: rudalics <at> gmx.at, stephen.berman <at> gmx.net, 70213 <at> debbugs.gnu.org,
 juri <at> linkov.net
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Mon, 08 Apr 2024 14:04:27 +0300

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

WDIT about what?

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stephen Berman <stephen.berman <at> gmx.net>,
 70213 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Tue, 09 Apr 2024 09:24:30 +0300

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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stephen Berman <stephen.berman <at> gmx.net>,
 70213 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Tue, 9 Apr 2024 11:03:36 +0200

> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: martin rudalics <rudalics <at> gmx.at>, 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Tue, 09 Apr 2024 21:24:54 +0300

> From: Joseph Turner <joseph <at> breatheoutbreathe.in>
> Date: Tue, 09 Apr 2024 09:38:40 -0700
> 
> >> From: Joseph Turner <joseph <at> breatheoutbreathe.in>
> >> Cc: Juri Linkov <juri <at> linkov.net>, Stephen Berman <stephen.berman <at> gmx.net>,
> >>  70213 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> 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.)

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Tue, 09 Apr 2024 22:12:19 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Joseph Turner <joseph <at> breatheoutbreathe.in>
>> Date: Tue, 09 Apr 2024 09:38:40 -0700
>>
>> >> From: Joseph Turner <joseph <at> breatheoutbreathe.in>
>> >> Cc: Juri Linkov <juri <at> linkov.net>, Stephen Berman <stephen.berman <at> gmx.net>,
>> >>  70213 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> 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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Wed, 10 Apr 2024 10:47:36 +0200

> 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

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70213 <at> debbugs.gnu.org,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Wed, 10 Apr 2024 20:40:43 +0300

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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70213 <at> debbugs.gnu.org,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Thu, 11 Apr 2024 11:17:17 +0200

> 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

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70213 <at> debbugs.gnu.org,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Fri, 12 Apr 2024 09:45:48 +0300

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.

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Juri Linkov <juri <at> linkov.net>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 Stephen Berman <stephen.berman <at> gmx.net>, 70213 <at> debbugs.gnu.org
Subject: Re: bug#70213: Info-mode side window fit-window-to-buffer issue
Date: Fri, 12 Apr 2024 00:12:19 -0700

Juri Linkov <juri <at> 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

Previous Next

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