Re: Error during redisplay

[Stefan Monnier]

>> 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.

Hmm.. I'm confused.  The auto-composed property is boolean, so at least
the auto-composition-mode code should only run once and should hence
generate a `composition' property value that does not depend on the
font used.

Maybe what you're saying is that this `composition' property is later
changed by the redisplay code and this can be redone if the same text
gets displayed with another font?

> By the way, I think the slowness is mainly because the

What slowness?

> property generation is done by Lisp code through the
> function in composition-function-table and that involves
> generating many Lisp objects.

By the way, it might be good to replace the composition-function-table
(which is a char-table that maps chars to regexps and then to code) with
a lex-style FSM.  Such a thing would also be useful for syntax-tables to
be able to deal with multi-char lexemes (like "begin" and "end").

> 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.

Might be worthwhile as well, tho I have no idea if there's an actual
performance problem to solve here.  Going through elisp is also
convenient: I currently use font-lock in haskell-mode, sml-mode, and
coq-mode to compose things like "->" into "→", but auto-composition-mode
would seem like an even better fit.


        Stefan