bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Eli Zaretskii]

[You forgot to CC the bug address.]

> Date: Thu, 14 Nov 2013 09:22:14 +0000
> From: Robert Dallas Gray <mail@robertdallasgray.com>
> 
> See the screenshot here:
> 
> https://github.com/d11wtq/grizzl
> 
> >From the bottom, you can see: a text entry area; an information line; and
> then a list of candidate files (this is Grizzl used for completing read
> over project files).
> 
> All three of these elements, if I'm reading the code correctly, are
> contained in the mini buffer window, which resizes dynamically as the list
> of candidate files grows or shrinks.
> 
> For this to look right, it must be possible to set the size of the window
> to a given number of lines as the number of candidates changes. The
> library's maintainer uses 'set-window-text-height' to do this (see
> https://github.com/d11wtq/grizzl/blob/master/grizzl-read.el#L141).

A side question: why does grizzl resize the minibuffer by hand,
instead of letting the display engine do that?

> In the case where line-spacing is non-zero, 'set-window-text-height'
> doesn't size the window correctly, as we've discussed. If we use a 'rough'
> number of lines based on the ratio described by Eli, then much of the time
> the window will also not be sized correctly, and as the list of candidates
> changes size, the baseline of the window (the text entry line) will
> 'bounce'.

This problem cannot be avoided entirely, and if it exists (did you
actually try my suggestion?), then the package has it already.  Those
2 lines, the "information line" and the line showing the best
candidate, they both use special faces, don't they?  If so, the same
problem will happen if one or both of these faces will use a different
font.

IOW, you cannot resize a window "exactly" like you would like to, in a
GUI session, simply because the Emacs display features are too many to
take everything into account, certainly if one works only on the Lisp
level.

You could say that users should not shoot themselves in the foot by
customizing these faces so as to disrupt the display of grizzl, but
then I could tell you the same about using line spacing.

> I can see that it's not possible to give an accurate window-text-height in
> the case of a display where fonts of multiple sizes might be used in the
> same buffer, but should it not at least take into account the global
> setting of line-spacing, and the height of the default font?

I don't see how line-spacing is different from any other feature that
affects the height of a line (except that you use the former, but not
the latter ;-).

> And, if it's impractical to fix this, is there a way to set the
> height of the window in pixels rather than lines so that the same
> effect can be achieved?

What makes you think that setting window height in pixels would solve
this issue?  Granted, the "jitter" would probably be smaller, but a
human eye can easily spot even a 1-pixel jitter, and be no less
annoyed.

What I'm trying to tell is that it is simply impossible to control the
Emacs display in Lisp to such a degree of precision, not with the way
the display engine is currently designed and implemented.  Whoever
designs packages which try to do that should be acutely aware of these
limitations in the first place, and if they don't avert her, at least
mention them in some prominent place.

Btw, I don't really see why there was a need for using the minibuffer
here.  Why not code a customized *Completions* buffer instead?  That
would at least make sure the "text entry area" could simply use the
minibuffer, which would then remain of a constant height, ever.