Re: Error during redisplay

[Kenichi Handa <handa@m17n.org>]

In article <85ir0aubo1.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > The current design requires to add `composition' property to a string
> > to properly display the string if it contains, for instance, some of
> > Indic characters, and to add `auto-composed' property to avoid the
> > repeated generation of `composition' property.
> >
>>> If they SHOULD have these properties, probably we should make sure they have
>>> these properties from the start, or from an early point in building Emacs.
> >
> > That's impossible.  How to compose them depends on which
> > font to use.

> Since the same string can be displayed with different fonts
> simultaneously, this would look like a fault in the design.  The
> composition property/whatever apparently needs to be associated with the
> actual display, not just the string.

In such a case, the composition property is generated each
time.  The same situation happens when you display the same
portion of a buffer in two frames with different fonts.

It may result in a little bit slower redisplay.  If such a
situation happens often and the slowness is so painful,
perhaps the composition property must be an alist of fonts
vs the current value.  It's not that difficult to implement.

By the way, I think the slowness is mainly because the
property generation is done by Lisp code through the
function in composition-function-table and that involves
generating many Lisp objects.  With unicode merge, the
underling actual task of deciding glyphs and positions is
mainly done by C functions of font-backends, and that should
not be that slow.

So, another way is to re-design the current redisplay engine
to generate a composition glyph every time just by calling C
functions.  I think it's an interesting experiment.

---
Kenichi Handa
handa@ni.aist.go.jp