GNU bug report logs - #50178
28.0.50; Size of echo area does not account for line-spacing

Previous Next

Full log

View this message in rfc822 format

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, 50178 <at> debbugs.gnu.org
Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing
Date: Wed, 25 Aug 2021 22:10:03 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Any graphics environment worth its salt has methods for measuring
>> whatever object without actually rendering it.
>
> So does Emacs: that's what window-text-pixel-size does.

You missed the part "without actually rendering it".

As per Martin's instructions, the method for ensuring that the text does
not overflow the window is to put text on it, one line at a time, and
watch the used space (I guess that two lines would be enough to
extrapolate the space required by N lines assuming that the text is
rendered with the default font, face, etc)

On the case of ido-grid-mode (which displays a grid N lines tall that
virtually expands horizontally) not knowing in advance how many lines
are available means that it must populate the mini window with some
dummy text to measure its capacity, throw away its contents and proceed
to fill the mini window with the real payload.

>> If an integer, it specifies the maximum height in units of the
>> mini-window frame’s default font’s height.
>> "
>> 
>> Why that was implemented that way? (instead of using pixels, for
>> instance.)
>
> Because in most cases it's more useful: it approximates the actual
> number of lines quite well.

Exactly, that was my point all along. And it would be a better
approximation if the display engine used that variable taking into
account line-spacing and other relevant settings which affect how the
actual text is rendered.

Previous Next

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