Re: The future of XEmacs

steven Mitchell writes: AFAIK they do, but only on some platforms (probably only on Windows, although some might exist on Motif. I suppose it should be documented, but I don't consider it a problem that some features work on only certain platforms. Bug reports would help. That's not the rule. We will veto patches that break a package that currently works with 21.4, but there's nothing wrong with using a feature that exists in some versions but not others as long as it is properly protected by feature test (just as you can use a feature that exists in an XEmacs that is configured --with-x11=yes but not one configured --with-x11=no). Alternatively you could use a version test but that's to be avoided where a feature test is available. Did you submit the code and have it vetoed for that reason? I don't recall it. Well, as I said above, version number is not a blocker, you just can't substitute code that depends on features not in XEmacs 21.4 for working code. As far as the bump goes specifically, XEmacs 21.5 is still really rough-edged in many ways. At a minimum the coding systems need to be fixed so that it's impossible to save a buffer with unencodable characters in it. I'd really like to fix the damn progress bar crash. I don't think there's much point in bumping the version number until we've got font-lock compatible with recent GNU APIs (ie, jit-lock). Coding system defaults are still not robust (although Aidan has banged them into pretty good shape, there are still some issues). Coding detection is not yet as accurate as it was before Ben reworked it, and Unicode as the internal encoding would be nice. I personally think that reasonable font support is a blocker (Xft or Pango), but I wouldn't try to veto a version bump if others disagree with that opinion. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta