GNU bug report logs - #37563
27.0.50; fit-frame-to-buffer does not account for line-spacing

Previous Next

Full log

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

From: Ingo Lohmar <ingo.lohmar <at> posteo.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 37563 <at> debbugs.gnu.org
Subject: Re: bug#37563: 27.0.50; fit-frame-to-buffer does not account for
 line-spacing
Date: Sat, 05 Oct 2019 11:05:18 +0200

On Sat, Oct 05 2019 10:41 (+0200), martin rudalics wrote:

>  > Okay, then I truly don't know how to write that succinctly.  I suggest
>  > to keep using the char-height (and the `frame-resize-pixelwise'
>  > docstring) for the time being, that is, not change the code in the last
>  > part of the function.
>
> If I don't use 'frame-char-height' here, any subsequent resize
> requests for that frame (including resizing the frame by dragging its
> boder with the mouse) might use the line height value.  In general,
> this is certainly not TRT, for example, when another buffer gets
> displayed in that frame's window.  That's also why I'm still reluctant
> to use the line height concept more pervasively.

Just to be clear: I do not see any problem with keeping using
`char-height' (the result of `frame-char-height') here; I only thought
that it is unfortunate that we cannot remove at least some tiny bit of
complexity.

> The particular problem could be resolved by adding a
> 'resize-pixelwise' frame parameter whose value, when set, would
> override that of 'frame-resize-pixelwise'.  Provided your frame is
> in some sense private to 'company-posframe'.
>
>  > Personally, I will simple set `frame-resize-pixelwise' to t.
>
> I don't think, however, that this problem is grave enough to warrant a
> general recommendation.  Adding all sorts of window and frame
> decorations to the value returned by 'window-text-pixel-size' will
> often add some slack whitespace when 'frame-resize-pixelwise' is nil,
> regardless of whether we round by character or line height.

I think I understand better now, I was hampered by some weird debugging
artifacts in my current setup.  With the default
`frame-resize-pixelwise' of nil, and the otherwise bug-fixed code,
nothing is cut off, but there is some slack whitespace, indeed.  The
frame parameter solution could address that, but adds even more
complexity..

From your explanation I think we should just live with it for the time
being.  No need for a general recommendation also, it was just a "TIL".

Previous Next

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