Re: position of line moves depending on visible chars

[Eli Zaretskii <eliz@gnu.org>]

> From: Yasushi SHOJI <yashi@atmark-techno.com>
> Date: Fri, 22 Jul 2016 09:01:05 +0900
> Cc: emacs-devel@gnu.org
> 
> > The behavior was changed in order to avoid huge line spacing when a
> > font reports a preposterously large height.  Any option such as the
> > one you are talking about will have to keep the new behavior whereby
> > the display engine doesn't user the font height for drawing the cursor
> > on empty lines, because this will have an even worse effects.
> 
> Are you saying that the change is to workaround bad fonts?

Indirectly, yes.  The previous code used the font-global size, both
for layout of a line with text, and for empty lines.  With those "bad"
fonts, non-empty lines could be fixed by using the dimensions of the
individual characters, but empty lines didn't have even that.  So some
different algorithm needed to be used, and that's what you see now.
I agree that the results are sometimes less than satisfactory, so if
someone can come up with a solution that doesn't re-introduce the
original problems, I'm for it.

> > It's impossible to keep lines at the same spacing when multiple fonts
> > are involved anyway, so the situation you are describing is not new.
> 
> Would you enlighten me about this? (A link to bts would be fine.)

There are too many bits, unfortunately.  In a nutshell, the Emacs
display engine determines the height of each screen line and the
spacing between them after it traverses all the characters to be
displayed on that screen line.  Since characters in a line can have
different faces, including faces that define use of non-default fonts,
the results of this cannot be predicted in advance.

For a simple example of what that does start the Emacs Info browser,
and look at the chapter and section header lines: they are taller than
the rest.

> Are you saying that the working Emacs 24 is a pure luck? (having
> good fonts?)

In a way, yes.  Try setting your default font to Latin Modern Math,
and see what happens in Emacs 24.5 and in Emacs 25.  Bug#20628 has the
details.