Re: Pixel-based display functions

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> I just don't want Elisp code to compute pixel sizes based on
>> glyph info.  It's what the C code already does.  So whenever Elisp code
>> tries to do that, it's a mistake (not so much because we should do it
>> in C, but because we end up having to reproduce in new code what
>> existing code already does, which is exactly what's going on with this
>> whole discussion about guessing which chunks of text will use the same
>> font and how we should handle chars which aren't covered by the font
>> etc...).

> I don't think Lars's Elisp does what the display engine does.

All I know is that his code will give wrong results if it doesn't
reproduce faithfully enough what the redisplay does.  And that to me is
a clear sign that it should reuse (some part of) the redisplay code,
since it's the simpler and most reliable way to make sure that the
behavior is faithful.

> (Of course, he could insert each string into a scratch buffer, but
> that's a waste, and doesn't solve the other problem, described below.)

I think this "waste" would be negligible.

> Second, there's a subtlety in move_it_* functions that was never
> explicitly raised in this discussion, but which becomes rather
> important if you want to consider reusing the move_it_* functions for
> this use case: they produce glyphs in the _visual_ order.  So if the
> text to be rendered includes R2L characters, you might break text
> between screen lines incorrectly.  (If this isn't clear enough, I can
> elaborate.)  Also, you will have to deal with the situation where
> (position-of-pixel-in-text FROM TO) is _less_ than
> (position-of-pixel-in-text FROM (1- TO)).  That is a complication that
> Lars would surely like to avoid, I presume.  By contrast,
> font-get-glyphs works in the logical order.

I think solving this problem is *hard*.  The problem is not just whether
you work on the logical or visual order, but in order to get the right
behavior when filling bidi text inside columns, is that you'll have to
partly reimplement the bidi code.  Maybe the best approach would be to
make position-of-pixel-in-text return some info about the reordering
that redisplay performs.


        Stefan


PS: who still would prefer refilling single-column text in the redisplay
itself, since it makes it lazy, and makes it work right even when the
buffer is displayed in different windows/frames with different fonts.