emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error during redisplay


From: Stefan Monnier
Subject: Re: Error during redisplay
Date: Thu, 28 Feb 2008 11:44:56 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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

> Yes.

I see.  So this is not directly related to the auto-composition-mode.
It can appear just as well with composition properties applied manually.

>> > By the way, I think the slowness is mainly because the
>> What slowness?
> Slowness of calculating composition properties.

I'm not sure whether by "calculating composition properties" you're
talking about the work done by auto-composition-mode to add
`composition' text properties where necessary, of the work done by the
redisplay to compile those properties into some other representation
(which I'd propose we call "compilation" of composition properties).

Also, I still don't know what slowness you're talking about: in which
circumstance is it slow?

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

> Does FSM stands for Finit State Machine?

Yes, I meant a deterministic finite state automaton (DFA).

> Currently those regexps are very simple, and just an alist
> (((FROM-CHAR . TO-CHAR) FUNC) ...) will work.  But, at the
> moment, I'm not sure that such a simple specification works
> for all scripts.

For my application this won't be sufficient because I do things like map
"lambda" to λ (for example).  Of course, I could just catch "la" and
then use FUNC to do the rest of the matching.

> But, if we can't attach `auto-composed' and `composition' property to
> a buffer, the requirement for the speed will be higher.  We have to do
> some experiment to check the performance.

> Another idea is to have an alist of
>   (FRAME . INTERVAL-FOR-COMPOSITION)
> for each buffer.

Not sure how this would work for strings.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]