Jerry James <james(a)xemacs.org&gt; writes: Most packages don't use the very fancy features of extents/overlays, so porting is usually trivial. I don't think we should introduce new packages that depend on wobbly "compatibility" API's, and introducing the first one was in fact a huge mistake, second only to the mistake of putting fsf-compat in SUMO. We don't have any point motion hooks, so inhibiting them is as easy as it gets. :-) When we get point motion hooks, we'll get inhibit-point-motion-hooks as well, so I believe you shouldn't worry about it.

Hrvoje> Jerry James <james(a)xemacs.org&gt; writes: Hrvoje> Most packages don't use the very fancy features of Hrvoje> extents/overlays, so porting is usually trivial. I don't Hrvoje> think we should introduce new packages that depend on Hrvoje> wobbly "compatibility" API's, and introducing the first Hrvoje> one was in fact a huge mistake, second only to the mistake Hrvoje> of putting fsf-compat in SUMO. Heh. You've almost got me convinced to preapprove a patch to substitute Scheme for elisp. ;-) I think just about everybody but rms agrees that extents are at least as good an interface as overlays, and most people think they're better. However, as long as the GNU Emacs interface is overlays, we're going to lose out on a fair number of nice packages that we don't have the manpower to maintain. Not to mention the huge number of packages that explicitly avoid using nice XEmacs features because they don't work on GNU (and then adopt whatever anemic incompatible thing GNU comes up with, cf toolbars). Is it really worth it just to be right? What do we really get from having the superior API here? Or with toolbars? Or glyphs? Or specifiers? Or anything? :-( -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: I don't know the answer to that. But I do know that not every "third party" package in the wide world needs to be distributed by us. If third-party elisp developers are in no way interested in making their packages work under XEmacs or be distributed with XEmacs, then maybe they shouldn't be. On the other hand, if the packages are so cool or important that they have to be in anyway, then they can be ported by an interested party on our side. If noone can be bothered to do the work for a package, perhaps its importance is overrated anyway. This doesn't answer the broader question of "why bother", but it sums up (the relevant part of) my position on choosing which third-party code to package.

"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.

Hrvoje Niksic <hniksic(a)xemacs.org&gt; wrote: I would say that this line of argument logically extends to the following: we should be building compatibility libraries so that Emacs programmers can use the XEmacs APIs there, too, rather than the other way around. Some examples showing the power of the XEmacs interfaces wouldn't hurt. In a strange twist of fate, that brings us back to the subject line, since hideshow.el became simpler in several ways when I ported it to extents. -- Jerry James http://www.ittc.ku.edu/~james/

* Norbert Koch <viteno(a)xemacs.org&gt; writes: No. You can't. Here's why... (package-get-list-packages-where 'fsf-compat 'requires) =>(erc ecb pgg perl-modes psgml-dtds ocaml sml-mode ess liece latin-unity mmm-mode tramp text-modes mail-lib jde edit-utils clearcase xslt-process egg-its leim mule-base psgml ilisp reftex prog-modes idlwave semantic bbdb mew tm mailcrypt mh-e eudc apel) ...you would have to remove all of those as well, and any package that depended on any of these, and so on. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | XEmacs - The only _______ you'll ever need. | | Fill in the blank, yes, it's THAT good! | |------------------------------&lt;sryoungs(a)bigpond.net.au&gt;---|

Hrvoje> But imagine trying to port the extents API or the Hrvoje> specifier API under FSF. Agreed, those really can't be done in full. But there is a compatibility layer for extents available for GNU Emacs somewhere, that's about as good as overlay.el for those things where text properties are the wrong API. And Custom replicates most of what specifiers do, more or less, plus a couple of small tweaks that apparently specifiers can't do by themselves currently. Hrvoje> Not to mention things like toolbar APIs, glyphs, keymaps, Hrvoje> etc. The glyph issues reduce to specifier issues. In most cases where you just want an image for GUI and a text alternative for TTYs, there should be a way to kludge up a restricted API from GNU. AFAIK the keymap APIs are mostly the same, aren't they? It's just that GNU programmers often don't use the API, but if they did it should work, right? And if I can ever get out from under the spam flood, I've got a reasonable implementation of a toolbar API which provides the same set of convenience functions for XEmacs and GNU Emacs, and does something sane where the GNU Emacs API simply can't handle what XEmacs can (for example, because of all the cruft that GNU Emacs keymaps have accumulated, it makes no sense to try to insert a toolbar button at "third from the left", and IIRC there's no way to push a subset of buttons flush right in GNU; in those cases the implementation just willy-nilly inserts at the right-hand end of the toolbar). [The reason this hasn't been published already is that I puked my guts out when I realized that the GNU docs aren't free, not to us[1], and even months later haven't had the stomach to return to the project to remove the GNU manual quotes and rewrite documentation for the things that are kludged for the GNU side. And it really doesn't make much sense to publish it just for XEmacs.] Footnotes: [1] There is no small set of agents that own 100% of our copyright, not even the FSF, so we can't change it to FDL without rewriting everything that isn't provably 100% FSF-owned, or getting explicit permission from the authors. But we can't use FSF docs unless we change to FDL, or get the FSF's permission to use the docs under the existing XEmacs doc license (which is, of course, the old GNU Emacs doc license). -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Steve Youngs <sryoungs(a)bigpond.net.au&gt; wrote: It'll all be worth it when your kids get the high-paying basketball contracts and put you and your wife in Nikes for the rest of your lives. Yes, it would benefit, and no it wouldn't be easy. For one thing, next you'd want to have a "$RUN_WOULD_WORK_BETTER_WITH_BUT_CAN_DO_WITHOUT" or "$RUN_IF_YOU_PLAN_TO_PRESS_CTRL_C_Y_BUT_OTHERWISE_YOU_DONT_NEED_THIS". On the other hand, this touches on a subject I've thought about some. I think it would be really useful to have a general Lisp cross-referencing tool, something that would tell us that package foo makes calls to functions defined in packages bar and baz. If we had such a tool, we could: - automatically compute both compile-time and (the maximal set of) run-time dependencies between packages; - tell users when they try to invoke functionality in an uninstalled package, and maybe even offer to download and install the missing package. I even have the hubris to think I know how to construct such a tool. What I want to know is this: where do I put the information? It'll be fairly large, but it needs to be distributed with the packages somehow if we are going to use it for the second item above. That's why I asked on xemacs-design awhile back if that kind of information could be stuffed into the package index somewhere. What do you think? -- Jerry James, father of 3 1/2 kids http://www.ittc.ku.edu/~james/

Cleaning Cc's, we all read the list. Hrvoje> Creating a dumbed-down API implementable on both versions Hrvoje> is of course possible, but that approach is not without Hrvoje> problems. Whenever I see "easymenu" used anywhere, I Hrvoje> flinch. I don't like easymenu at all. But I think the reason is that easymenu is clearly written by someone who wants the programs they wrote for a VW Beetle to drive a Porsche 944. There's just no way to make the thing Autobahn-ready, even if you've got the engine for it. But we've usually refused to do the reverse. We'd rather suffer with our low-level glyph/image/specifier interfaces than provide something saner/higher-level that could smoothly handle what GNU images, menus, etc can do, while making access to the XEmacs facilities convenient. Hrvoje> Not really; for example, they use keymaps to implement Hrvoje> menus. "Why doesn't XEmacs have `define-key-after'?" And toolbars. But do people really use `define-key-after' to define _keys_? If we provided a decent compatible interface abstracted to toolbars or menus, don't you think there's a reasonable chance that 3rd party maintainers would be happy to forget the existence of such cruft entirely? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.