Hrvoje> If at all possible, it should be done with extents. Or text properties, which are occasionally an alternative (and have the advantage of having pretty much the same interface and semantics in both Emacsen). -- 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.

Hrvoje> "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: >> Hrvoje> If at all possible, it should be done with extents. Hrvoje> Except they're slow and buggy. Always have been. :-( The "buggy" I can't speak to. "Slow" is (AFAIK) a function of needing to coalesce and split extents due to deletion or addition of text lacking the property of the surrounding text. But this needs to be done, in many cases. Maybe the text properties code could be optimized a bit. But extents themselves can be extremely slow if you aren't working "in display order". They just lend themselves to caching, which is basically impossible with text properties. Hrvoje> More and more packages are using overlays, which also goes Hrvoje> to show that text properties are not as useful as Stallman Hrvoje> has made them out to be. Big surprise there. I agree with rms that they are quite useful in many situations. However, once you abstract from "text as a stream of characters" and start looking at document structure, you no longer have any way to get your hands on the text properties. And there are times when you'd like to structure a region even though it all has the same property. So they're quite useless (without kludging) for many modern applications. But you know how rms feels about "constraints" and "abstraction". -- 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.

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.