emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#50178: closed (28.0.50; Size of echo area does not account for line-


From: GNU bug Tracking System
Subject: bug#50178: closed (28.0.50; Size of echo area does not account for line-spacing)
Date: Wed, 25 Aug 2021 10:50:02 +0000

Your message dated Wed, 25 Aug 2021 12:49:39 +0200
with message-id <87k0k9er3w.fsf@telefonica.net>
and subject line Re: bug#50178: 28.0.50; Size of echo area does not account for 
line-spacing
has caused the debbugs.gnu.org bug report #50178,
regarding 28.0.50; Size of echo area does not account for line-spacing
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
50178: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50178
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 28.0.50; Size of echo area does not account for line-spacing Date: Tue, 24 Aug 2021 04:08:41 +0200
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



--- End Message ---
--- Begin Message --- Subject: Re: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Date: Wed, 25 Aug 2021 12:49:39 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
martin rudalics <rudalics@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.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]