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

From: Stephen Berman <[email-masked]>
Date: Sun, 07 Apr 2024 11:30:52 +0200

On Sat, 06 Apr 2024 18:59:45 -0700 Joseph Turner <[email-masked]> wrote:

> Stephen Berman <[email-masked]> 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