Christoph> Thus, my coding is in no way worse than the existing Christoph> XEmacs coding. Oh, I didn't realize that you were referring specifically to the info-look library. D'oh. Yes, if the existing library already uses overlay.el, we should require it. [Note that since info-look is in the edit-utils package, it has nothing to do with XEmacs 21.4.5. Except that it (presumably) runs in XEmacs 21.4.5.] Christoph> P.S. As I am not a friend of bigger Emacs-XEmacs Christoph> differences, I can try to get some more XEmacs friendly Christoph> coding into Emacs' version Well, I appreciate your effort. But I don't know how much effect there will be if most of the development is being done at GNU. The overlay-extent difference is one of the serious technical differences between the two implementations. I think it unlikely that the GNU people would be willing to uglify their code to accommodate the XEmacs extent API. And I have a hard time disagreeing, assuming they are going to continue using the overlay API. I would say the most likely approach would be to abstract that snippet into a function, and conditionally define it and the global overlay it uses depending on Emacs or XEmacs. Even if GNU doesn't want the conditional code, that would be easier for us to synch as a fork, since it could all be localized into a few lines in one place. -- 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.