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

[Robert Dallas Gray]

On 14 Nov 2013, at 18:07, Eli Zaretskii <eliz@gnu.org> wrote:

> [You forgot to CC the bug address.]
> 

Apologies.

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

No idea I'm afraid. I've linked to this bug in the issue I've raised on the 
Github repo, so perhaps the maintainer will drop in and enlighten us.

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

I did try the suggestion (or something like it), yes, and it resulted in the 
'bouncing' I mentioned.

I agree with your last couple of sentences, which is why my current workaround 
is to set line-spacing to nil in the minibuffer. But if it were possible to 
size the window in pixels, even the edge case you describe could be avoided.

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

For sure.

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

Well, I'd contend (as a former book designer) that line-spacing is *by its 
nature* an integral part of the height of a line of text (the clue's in the 
name). 

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

We can determine the height of a line of text in the relevant face, and its 
line-spacing, in pixels, and create a simple algorithm to calculate the total 
height of a given number of lines.

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

Again, for sure. If it's a hard limitation of Emacs, so be it.

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

Again, I dunno. I'm not the author, and I'm crediting him with having done 
things the way he has for good reasons. Hopefully he'll show up at some point 
and explain.

In the meantime, I'd suggest we shelve this one. Thanks a lot for taking the 
time to engage.