>> "Tassilo" == Tassilo Horn <t...@gnu.org> writes: > Uwe Brauer <o...@mat.ucm.es> writes:
> It's only in Git head. The ELPA release is basically 11.87 + some > bugfixes, but no new features. >> I cannot use ELPA for xemacs :'(. > Ah, I've though you've switched over when reading your latest mails. ;-) > Well, then you probably should use the Git version. No, no, this was for various flavors of GNU emacs on a Mac for some friends. I still stick to Linux and for the time being to Xemacs[1] >> The reason why I am asking this, is the fact that I am now convinced >> that 11.87 has some important improvement over 11.84 > We very much hope so! And the git head has many improvements over > 11.87, too. Now I am confused. You just stated that they are only bug fixes now you say that git head has "many improvements" ok one could interpret bug fix as improvement but this is really what you mean??? >> and therefore I[1] would like to release an official version of its >> corresponding xemacs pkg (that is the Xemacs's more than a decade old >> counterpart of EPLA).[2] > Ah, I guess you mean the xemacs package for the xemacs package manager, > not the xemacs AUCTeX release we're rolling on our own, right? Right. > Out of couriosity, what's the hurdle/difference of our official > AUCTeX XEmacs package and the official XEmacs AUCTeX package in the > XEmacs package repo? This is a long and sad story, subject to many flamewars between David Karstrup and Steve Turnbull, better let us drop the subject. Just two comments, one difference, I think, has to do with the autoload files, the other more important one: we have a hierarchy of packet managers. One for the individual ones, another one for the whole beast and it is not trivial to include your Makefile in our Makefile hierarchy. For example when there was a big jump, from 11.55 to 11.84 if I recall correctly: the one when preview was somehow rigidly included into auctex, it proved easier to adopt our Makefiles to the new structure that the other way around (I don't remember all the details too well). >> In order to do so, I would rather not base it on the version found on >> the webpage, but instead I really would like to include at least Moses >> patch. About the other enhancements I cannot judge since I did not try >> them out so I would rather stay away from the git version. > I can understand that, but I have nothing to offer. You > could just grab the 11.87 release and patch it with the > fixes and enhancements you like. Or as said above, wait for > 11.88, but of course that will be released From the git > head, so more testing effort on your side. Right, any time schedule for 11.88? > Surely, no. In an ideal world, I'd simply drop all compatibility, all > the build complexity, and simply develop AUCTeX in the ELPA repo (or > keep the ELPA AUCTeX branch in strict sync with the AUCTeX git repo), > and only do ELPA releases. For users, that's by far the easiest and > fool-proof way of getting AUCTeX, and for us maintainers, that's the > easiest way to cut new releases. > Now of course, that would exclude XEmacs and users of older emacsen, so > that's not realistic for now. But it would suit me as a maintainer who > favors releasing frequently, preferably after every single fixed bug and > every new feature. Please don't exclude xemacs, realistically now I have nothing to offer than a polite request. >> Are there alternatives? > I'm not sure. I think, the existence of the official XEmacs package > versus the XEmacs AUCTeX release has mostly non-technical reasons, but > I'm not remembering details. I am not sure here neither but I think there were technical reasons. > With respect to ELPA and Git: the problem is that ELPAs file and > directory structure is different (that's a restriction), and the ELPA > repo doesn't have the complex build stuff. It would be very, very, very > valuable if someone with better makefile foo than me would restructure > the AUCTeX Git repo according to the restrictions of the ELPA machinery, > so that if fact the auctex ELPA branch and the official AUCTeX git head > were the same. ok Thanks Uwe Footnotes: [1] I confess I have to use GNU emacs 24 for Hebrew, well this is not entirely correct, the gtk branch of Xemacs has some BIDI support but alas the GNU emacs BIDI engine is far better :'(
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel