bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 01:21:56 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, 18195@debbugs.gnu.org
> 
> > For example, AFAIU, your code currently assumes that the font used for
> > popup is the same as the one used for the underlying buffer text.  But
> > since you provide faces for the popup, a user could legitimately
> > customize those faces to use a different font, and thus invalidate
> > your calculations, because window-screen-lines uses the metrics of the
> > default face's font.
> 
> Sure. This doesn't add any constraints over what we've been living with 
> for years.

Until some user would ask to lift them.

But if you never want to lift them, why not define colors instead of
full-fledged faces?  Then those restrictions are really carved in
stone and clear for all.

> > IMO, instead of overloading existing display features with jobs they
> > were never designed to do, and then live forever with the situation
> > where development breaks the resulting applications (like the
> > pixel-wise resizing of windows did with this one)
> 
> pixel-wise resizing wasn't actually the culprit: I've just never tested 
> the code with non-zero line-spacing.

The bug had two parts; one of them _was_ due to pixel-wise resizing.

>  > it would be a much
> > better investment of energy to come up with requirements for Lisp APIs
> > that could be used by applications for laying out text.
> 
> That sounds great, but I don't even know where to start. What we're 
> trying to emulate, though, is multi-layered display. That sounds 
> somewhat different from a "text layout API" to me.

I don't mind how it is called and what is the correct abstraction.  I
do know that we need some abstraction and APIs to support it.  If you
already know what the correct abstraction is, then you are in a good
position to formulate the requirements.