Re: XEmacs at a crossroads

Raymond Toy <[email protected]> wrote:

>     >> I don't have any suggestions on the way forward, but [3] seems
>     >> like not such a good idea.
>
>     Stephen> Yeah, we know that.  But it's the only way we've thought
>     Stephen> of so far to get back to feature parity.
>
> Does anyone see this as a viable alternative?  XEmacs would be Emacs
> until someone puts in all of the XEmacs bits back in.  That seems like
> a fair bit of work.  And then what?  Won't XEmacs be in the same boat
> as it is now, except that it's much closer to Emacs than it is now?

  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
[email protected]
http://lists.xemacs.org/mailman/listinfo/xemacs-beta