Re: XEmacs at a crossroads

Raymond Toy <toy.raymond(a)gmail.com&gt; wrote: In fact, I don't think it's such a bad idea at all and it would certainly tickle my motivation again (to some extent). First, a fork of Emacs is just a branch on github these days. I've actually done so already for a couple of features that I wanted, which would likely not be accepted as is (and weren't). Many other people have done this as well already. Next, keeping up to date with Emacs is much simpler that way, since it would boil down to merges (of course it's more complicated than that, but I mean at least, the underlying RCS infrastructure make the process much simpler). Then of course, there's the (original) question of what you actually want to do in the XEmacs "branch". As I said before, I don't miss any end-user-level, practical, features. It's actually quite the opposite. I do miss our level of data abstraction and some APIs. If we manage to provide alternate APIs (say, extents) and make them co-exist with the original ones, that's cool. Data abstraction is more problematic (particularly if we turn things into opaque types) because their current way of exposing every abstraction's family jewels to the wild (boy, the number of things that are actually just lists!) makes it likely, or at least easy for external packages to access every single feature in every possible dirty way. We would likely break a lot of code. Let me just add one more thing: being an Emacs branch could also be an incentive for them to actually incorporate things back from us, as long as it boils down to merging (or accepting pull requests for that matter). -- ＠-quartet live: Sunset/Sunside, Paris, Jan 26 2016 ! Book now: http://www.sunset-sunside.com/2016/1/artiste/2101/3453/ Lisp, Jazz, Aïkido: http://www.didierverna.info _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta