GNU bug report logs -
#50178
28.0.50; Size of echo area does not account for line-spacing
Previous Next
Reported by: Óscar Fuentes <ofv <at> wanadoo.es>
Date: Tue, 24 Aug 2021 02:09:02 UTC
Severity: normal
Found in version 28.0.50
Done: Óscar Fuentes <ofv <at> wanadoo.es>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#50178: 28.0.50; Size of echo area does not account for line-spacing
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 50178 <at> debbugs.gnu.org.
--
50178: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50178
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
martin rudalics <rudalics <at> gmx.at> writes:
>>> It must know and handle every setting that affects line height, current
>>> and future. It would be handy if Emacs provided a function that does
>>> that.
>>
>> We already have it: window-text-pixel-size.
>
> To elaborate:
>
> (1) You first have to calculate the maximum permissible pixel height of
> the echo area window from the character height of the frame where
> you intend to display the completions and the value of
> `max-mini-window-height' height as specified for that frame. Note
> that for a minibuffer-less frame the echo area window may appear on
> another frame whose character height you have to use here.
>
> (2) You then have to calculate the pixel height of each completion line
> as if it were shown in the echo area window mentioned in (1) using
> `window-text-pixel-size' and add it to some cumulative height until
> you have exhausted the maximum permissible height calculated in (1).
Thanks. That's too complicated and looks like there are quite a bit of
hidden traps, so for the time being I'll set line-spacing to nil.
On true pixel-oriented systems there are APIs for querying the display
engine about several metrics. Then you can place the text at certain
pixel coordinates. Emacs, however, is a Frankenstein system, that uses
pixels (on graphic frames) but the text positioning depends on previous
text, i.e. for vertical positioning it is a line-based, not pixel-based,
system. Therefore, when you just need to output some lines, you must
deal with pixels, translate back to lines and, to add insult to injury,
resort to post-facto information.
As useful as it would be an API that returns how many lines fit on a
given window. Or, on this case, max-mini-window-height being a true
indication of the capacity of the mini window on terms of the current
display settings, which is what the users want 99.9% of the time.
Closing.
[Message part 3 (message/rfc822, inline)]
Seems that on some circunstances the vertical space calculated for the
text on the echo area does not account for the value of line-spacing:
emacs -Q
M-x icomplete-vertical-mode
M-x fido-mode
(set-default 'line-spacing 0.1)
Now M-x will display a list of candidates with the last candidate
partially visible for lack of vertical space.
In GNU Emacs 28.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0)
of 2021-07-30 built on sky
Repository revision: d9bc7dbefd88995d04b9843f521d82118265fecf
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure --with-native-compilation --without-toolkit-scroll-bars
--with-x-toolkit=lucid --with-modules --without-imagemagick
build_alias= host_alias= target_alias='
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND THREADS TIFF X11 XAW3D XDBE XIM XPM LUCID ZLIB
This bug report was last modified 3 years and 272 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.