GNU bug report logs - #18195
24.3.92; window-screen-lines is not accurate

Previous Next

Package: emacs;

Reported by: Dmitry <dgutov <at> yandex.ru>

Date: Tue, 5 Aug 2014 02:01:01 UTC

Severity: normal

Found in version 24.3.92

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18195 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#18195: 24.3.92; window-screen-lines is not accurate
Date: Wed, 06 Aug 2014 18:15:00 +0200
>>>> This would have to be done on the Lisp level by selecting some font
>>>> before calculating the size of the overlay.
>>>
>>> Which font would you select?
>
> You didn't answer this question.  The only trivial answer is the font
> of the default face, a choice which has the problems described below.

I probably did no understand it.  I do not want to select any font.  The
application has to know which font the overlay should appear in.  If its
the font of the buffer where the overlay finally appears, it should take
this.  If it wants to use any other font, it should take that.

>>> I'm talking about a situation where the text over which the
>>> candidate list will be popped uses several different fonts, and so
>>> each line of the buffer text has a different height.
>>
>> I would pop up that list in a temporary buffer and run
>> `window-text-pixel-size' over it.
>
> And therein lies the problem.  You will get the size of the text under
> the assumption that the text will be displayed using a single font,
> the one used by the frame's 'default' face.  But if the text in the
> region over which you will pop the candidate list uses a different
> font, or shows images on some of the lines, the pixel height needed to
> display the popped list will be different.  That's because the
> candidates are displayed by Company by putting overlays on consecutive
> lines of text, each overlay showing one candidate.  However,
> displaying such overlays in the middle of a line of buffer text cannot
> decrease the height of the line, it can only increase it.  Therefore,
> if the line of buffer text was taller than what is required for the
> default face's font, the displayed overlay string will take up more
> pixels than what you measured in the temporary buffer.

But as I explained in my mail to Dmitry this is the problem of the
application.  Whatever it wants to do in the target window it has to
emulate in the temporary buffer: Put the original text there, apply any
font or property settings from the original buffer to that buffer, put
any overlays there, apply any font or property settings for the overlays
there, and have move_it_to get the overall height.  What am I missing?

martin




This bug report was last modified 10 years and 289 days ago.

Previous Next


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