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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 05 Aug 2014 14:03:37 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 08/05/2014 12:38 PM, martin rudalics wrote:
> > IIUC
> >
> > https://github.com/company-mode/company-mode/issues/160#issuecomment-51022508
> >
> > mentioned in that thread, all you want is to display all lines of a
> > completion buffer.  Is that correct?
> 
> Not at all. Have you tried Company?
> 
> This issue is about completion popup, which displays completions in the 
> current buffer and window, in a rectangle rendered using an overlay. 
> There are screenshots in that issue thread.
> 
> Before the popup is rendered, we need to determine how much of it would 
> fit below the current line, and if there's not enough space, we render 
> it above the current line.

I fixed window-screen-lines.

However, please note that you are on a slippery slope doing this.
Emacs currently doesn't provide Lisp interfaces that would allow to
perform such layout tasks from Lisp with reliable results.  Overlays
and text properties were never supposed to be used for layout
purposes.

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.

And that is just an example of what could go wrong when you try to do
what in Emacs can only be done reliably by the display engine.

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), 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.  These
requirements, when implemented, would then benefit everybody, and
allow solid dependable applications that don't break that often.