Re: Hideshow

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: I believe "a little effort" is a way too optimistic assessment. In fact, I'd venture to say that it's a losing battle of a different kind. Here are the reasons: * There is no standard to adhere to, only incomplete documentation and the moving-target code base of the competiting implementation. * The users and developers have very high expectations of the compatibility code. Most people program by trying things out, not by reading the documentation. Each case of a compatibility function behaving differently from FSF in a corner case is is one more bug for us to fix. These expectations are almost impossible to meet without importing the entire FSF code base. (The developers of the Microsoft Office clones face a similar problem when importing MS-software-generated files.) * Previous attempts to do this have not been very successful, to say the least. The text properties implementation is *still* a source of problems: it's slow, unreliable, incomplete, and in places simply incompatible with the FSF. The same applies to almost all non-trivial emulation layers. overlay.el, timer.el and the likes all differ from the FSF originals in subtle ways. * Third-party developers who might otherwise bother to learn our API's see the compatibility layer and use it instead. Then they no longer need to "port" their package to XEmacs: it is enough that it works in FSF, everything else being up to us. Thus we spend time making XEmacs bug-to-bug compatible with the kludgy FSF API's instead doing something more productive or fun. fsf-compat should exist, but it should only serve as a quick&dirty way to port FSF or third-party code. Shipping it in SUMO by default makes it the /de facto/ standard part of XEmacs, bringing more harm than good.