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

|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: 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.:-) SJT> Well, I did a little looking around in the process of trying to figure SJT> out what was going on here, and my conclusion is that it is not going SJT> to happen. Isn't that a bit of a defeatist attitude? It's not like it would be impossible to do and in most cases not hard either, just time consuming. SJT> We can do just a little more work, and get rid of all use of SJT> even the term "overlay" in the core. Yes, this should happen. SJT> But not packages. There are at least a dozen packages that use the SJT> overlay interface. It turns out that in most cases SJT> (defalias 'make-overlay make-extent) SJT> is sufficient. To me, this is a good argument for doing it. SJT> I think that what we ought to do is restrict the overlay interface SJT> even more than we've already done in overlay.el, signal on SJT> "inappropriate" usage (ie, _anything_ not compatible with the SJT> intersection of XEmacs extent and GNU Emacs overlay APIs). You mean sort of like the obsolete function thingy? Sounds good as part of the solution/fight. :-) SJT> Of course, we could write "extents.el" for GNU Emacs and see if we can SJT> get it past rms and EZ.... It has to be somebody who's signed their SJT> papers, of course. How would this work? What would 'extents.el' do for the FSF folk? -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|