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

Previous Next

Full log

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

Previous Next

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