Joris van der Hoeven wrote:
1) I don't think that functions like buffer-tree are "redudant": this is the *clean* way to get the current buffer tree.
Providing a clean API wich only provides means for getting the *current* buffer tree is good, and perhaps it is clean, but unfortunately it is also *incomplete* : very naturally, one is also lead to think about getting info about the other buffers.
In this respect, using "(path->tree '())" for getting the current buffer root tree is perhaps less clean, but on the other hand it is complete, in the above sense. And as soon as something is complete, all the other things that implement only a part of this something in a different way (even if it is done in a cleaner way) appear to be redundant. To avoid such problems, one should take care about providing clean and reasonably *complete* APIs in the first place.
2) It is good style *not* to work with paths when not necessary.
I agree with this. Working with objects thru pointer manipulation is the clean, and very classical way to implement a library for managing datastructures. Too bad it has not been done in the first place. Now we are stuck with these things with paths which are more confusing than anything else, althrough useful in some cases (like the example you gave).
Indeed, trees in the document *know* about their position
I didn't said it explicitely because it is a very usual property of objects. I could say as well that in C, objects *know* their address, and that you can fetch this address by means of the operator "&". But such an explanation appears to be redundant, provided you are sure that people know the very basics of memory allocation in a computer. Best, Henri _______________________________________________ Texmacs-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/texmacs-dev
