Re: Text properties slow down XEmacs

Hrvoje> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: >> >> Hrvoje> Jan Vroonhof <vroonhof(a)math.ethz.ch&gt; writes: Hrvoje> The font-lock code wants to apply certain properties to Hrvoje> parts of the buffer, merging or breaking the extents as Hrvoje> needed. This is exactly what the text-properties are for. Obviously I shouldn't be reading the verbal documentation, I should be reading the prototypes. The _doc_ says text properties are for attaching properties to characters; the _prototypes_ say they are for working with intervals. Hrvoje> Well yes, but imagine merging two comments or strings, or Hrvoje> splitting one. In that case you have to break an extent Hrvoje> in two parts, or merge two adjacent extents. This is Hrvoje> exactly what the text properties code is supposed to do. OK, I'll buy that now. Hrvoje> I think the code would be more complex if font-lock Hrvoje> attempted to do the merging/breaking by itself, but I Hrvoje> might be wrong. It would certainly be faster that way... Given that we implement text properties in terms of extents, I don't see a speed gain (modulo function call overhead, which I guess is pretty important), and I do see a complexity increase, from font-lock doing the merging/breaking itself. Your judgement is probably better than mine on that. Hrvoje> My point was that the "native" balanced-tree Hrvoje> implementation of text properties is bound to be faster Hrvoje> than emulating them with extents. Perhaps I am wrong on Hrvoje> that one, too. I would certainly *like* to be wrong on Hrvoje> that one. The way the text properties interface is defined, I really don't see them as anything but a restriction of the extent interface. However, the balanced-tree access method implemented for text properties by the FSF is something we should have for extents. Perhaps it should be used for functions like `extent-list' and `extent-at'. It also (or alternatively) might be useful to be able to create arbitrary balanced trees of extents corresponding to different orders. In the end, for redisplay we _must_ update an extent when we change a text property, for at least a significant fraction of the uses of text properties. We may as well implement the character ranges implicit in a balanced-tree implementation of text properties as extents, and get that update "for free". No? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091