Jerry James writes:
I have looked at using a Common Lisp engine for the analysis, but
Mule-encoded files make that difficult. One possibility is to have
XEmacs convert all Mule-encoded files to something else (probably
some form of Unicode) off-line, then feed the converted files to
the analysis engine.
Well, we can't really justify making Unicode the official coding of
Lisp in the near future (since 21.4 can't really deal with it yet),
but we need to do something about starting the transition soon.
folding. At a minimum, we have to know that (featurep 'xemacs)
and
running-xemacs are both the constant t,
GNU Emacs already has the byte-compiler fold those; we should do that
too, I think, if we don't already.
and we have to be prepared to perform a string-match on
emacs-version.
Why? Shouldn't we look for "(string-match \(.*\) emacs-version)" and
fold that if we recognize (match-string 1)?
Is anybody interested in working on something like this?
Jerry, you're looking at this the wrong way. Why should you care if
anybody is interested? It's clearly interesting stuff (although I
probably won't work on it myself). If alioth won't support an
arbitrary number of branches, I bet Canonical's Launchpad will.
That's one major reason for doing the dVCS thing. The only question
is do you want to publish.
Mebbe I should get Barry Warsaw to bring his soapbox over and preach
the wonders of unofficial public branches.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta