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

SY> I just think that we should be using our extents api whenever SY> possible instead of overlays. Now there's a nice little job SY> for some conscientious hacker, getting rid of overlays from SY> all the XEmacs packages.:-) Well, I did a little looking around in the process of trying to figure out what was going on here, and my conclusion is that it is not going to happen. We can do just a little more work, and get rid of all use of even the term "overlay" in the core. But not packages. There are at least a dozen packages that use the overlay interface. It turns out that in most cases (defalias 'make-overlay make-extent) is sufficient. It also turns out that nobody _ever_ does (defalias 'make-extent make-overlay) to make GNU XEmacs-compatible. In fact, what normally happens is (if (featurep 'xemacs) (defalias 'package-make-overlay make-extent) (defalias 'package-make-overlay make-overlay)) which is incredibly ugly. I mean, when Kyle Jones does that, we can just fold our hand and wait for a new deal right there. I think that what we ought to do is restrict the overlay interface even more than we've already done in overlay.el, signal on "inappropriate" usage (ie, _anything_ not compatible with the intersection of XEmacs extent and GNU Emacs overlay APIs). Then packages that need bug-compatibility with overlays can write their ugly compatibility layers. For the rest, we let people do what they're gonna do anyway, except pretty. Of course, we could write "extents.el" for GNU Emacs and see if we can get it past rms and EZ.... It has to be somebody who's signed their papers, of course. Comments? -- 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.