emacs-devel
[Top][All Lists]
Advanced

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

Re: Error during redisplay


From: Kenichi Handa
Subject: Re: Error during redisplay
Date: Thu, 28 Feb 2008 15:36:20 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, Stefan Monnier <address@hidden> writes:

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

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

> What slowness?

Slowness of calculating composition properties.

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

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.

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

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.

---
Kenichi Handa
address@hidden





reply via email to

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