Re: XEmacs-21.4.5 info-look; sync with Emacs-21.1

Dropping Christoph, I don't think this is relvant to him anymore. Hrvoje> Programs making heavy use of text properties will notice Hrvoje> the slowness, and it's a real problem. Er, font-lock does, now. Do you know if Mule would make it worse? (BTW, I plan to phone up Ben in the next couple of days, so don't work too hard on this. But I would appreciate a second opinion.) Hrvoje> You have to be pretty imaginative to make extents Hrvoje> "extremely slow", and the text properties code seems to Hrvoje> have exactly that kind of imagination. :-) I think you basically just need to ask for the biggest contiguous region satisfying a constraint and containing point, which is exactly what text-properties do. "Display order" is optimized to ask exactly the opposite question (get the most-nested extent). Note that before Ben changed the font-lock code to use text properties from a naive use of extents, it involved an n-squared algorithm. So I suspect there's a whole class of applications that naturally are slow using the basic extent API. I haven't seen much speedup, though, so I sort wonder if he maybe just ended up pushing the n-squared aspects to a lower level of code. Hrvoje> or mark a region of text and store the pointer to the Hrvoje> "marker", extents are the thing for you. This fits the Hrvoje> usage pattern of a surprising number of applications. Exactly. On the other hand there are a lot of applications where you merely want to query a buffer position. In those cases extents carry excess baggage. Having looked at both, I'm convinced that it's better to implement text properties in terms of extents rather than overlays in terms of marker-pairs, of course. But it would be nice if they were a little more efficient. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.