GNU bug report logs - #15886
24.3.50; Incorrect window-text-height with non-zero line-spacing

Previous Next

Full log

View this message in rfc822 format

From: Robert Dallas Gray <mail <at> robertdallasgray.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15886 <at> debbugs.gnu.org
Subject: bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing
Date: Thu, 14 Nov 2013 19:24:42 +0000

On 14 Nov 2013, at 18:07, Eli Zaretskii <eliz <at> 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.

Previous Next

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