David Kastrup writes: A minor correction. I've tried, and so has Uwe, both without success. I'm sure it can be done, but it's not high on my priority list. Since (aside from Uwe) I've still not seen any interest in contributing to an up-to-date binary package, it's not likely to get increased priority soon. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: *sigh* I give up. If somebody else wants to deal with David's insults and misrepresentations, feel free. I've got better things to do. One of which is working on the AUCTeX package (someday, probably not soon, as already mentioned). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David> "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Hello Since I am the person in charge (still) a couple of comments to the best of my knowledge. David> Well, I'd say the problem is that you are trying to modify David> the existing decades-old AUCTeX packaging in your tree to David> match the new requirements. That is my understanding of how the XEmacs package system works. I really can't judge since I don't feel qualified but that is what I have been told by the experts on that issue. This process however turned out to be complicated. The Auctex team has changed, quite drastically, the way of compilation. I presume the reason for this is the inclusion of the preview package. While I failed to compile it into the official XEmacs package tree in the time I had, I am somehow relieved to see, that persons like Stephen Turnbull had similar difficulties. Now I must add a technical question, David. I have only very briefly followed the discussions on the Auctex mailing list. But is it correct that you are planning also to include reftex into auctex? If so, that might lead to a change of the installation process? When is this going to be happen? David> That's just a bunch of unnecessary work. Just cut out the David> history. Let the AUCTeX Makefile build an XEmacs package David> tree (or a finished binary package): this generates all the David> necessary startup files with all the necessary relative David> paths. Then go backwards from the finished binary package, David> dissecting it into your source tree arrangement. David> All the files are there then. You just need to arrange them David> in your source tree order before the scripts compiling and David> copying them are run, and are finished. Are you _really_ sure of this David? I am not and that is why I try to follow the way the XEmacs package system requires things to be done. I think so. I would estimate about several days of work and unfortunately I had not the time for that and I must add no _other_ volunteers (besides Stephen) showed interest. [snip] David> Yup, what I said: XEmacs developers _will_ deny that anybody is David> interested in AUCTeX. To be fair I have not seen a overwhelming amount of calls for the upgrade. From time to time that subject appears in the list, right but not more. There might be an other reason for this. Auctex is now a *very* mature product. Yes I know it still gets improved but I guess for a lot of users it is satisfactory what it offers . I can tell from talks I had with my colleagues that some of them even are satisfied with, in my eyes, inferior products such as winedit and kile. Uwe Brauer _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Well point taken. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Thorsten Bonow writes: If you're a heavy AUCTeX user, switching to GNU Emacs makes a lot of sense. It's going to support AUCTeX better, for a variety of reasons, but the killer reason is that nobody in the core of AUCTeX development uses XEmacs except to test and diagnose bugs in AUCTeX. That is very unlikely to change in the near to medium term. There is also necessarily going to be a lag, which will vary from a few days (pre-release) to couple of weeks (public release) to several months (SUMO release), between an upstream release and the release of an XEmacs package for it. Because of that lag, I just don't think it's reasonable to hope for the XEmacs package system to stay current with all of the packages in it. For packages maintained by XEmacs users, sure, it's often trivial because they'll use XEmacs CVS as the repository. But for 3rd-party packages, the XEmacs version should be considered a convenience for users new to the package, or with basic needs. (Eg, I personally don't use any of the features of AUCTeX introduced since version 9.) To take a hint from the Python jargon, we do include batteries, but not high-power alkaline ones. What I think should be done for projects like AUCTeX and ESS and even VM is to make it possible to easily get packages built by upstream from the upstream site (or another 3rd party site, for that matter). Then people who just use XEmacs packages can try the package, which might be fairly old, and if they decide they want the latest and greatest, they will have the *convenient* option to update from a 3rd party site. Much of the infrastructure for multiple download sites is there, but it's not very convenient, and for VM, ESS, and AUCTeX at least the URLs are well-known and should be queryable from our package infrastructure. The other aspect that needs improvement is bug reporting. We need to set up a generic bug reporter so issues with packages with substantial lags in release compared to upstream are *very* easy to report to XEmacs, and relatively painful to report to upstream, and the opposite should be the case for third-party distributions of packages (including upstream). Whether that would help you stay with XEmacs is up to you. But those are two areas I've been thinking about improving here. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: Yes:-), but the generic bug reporter is a separate requirement. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> I'm sure it can be done, ... I have tried to follow this subject earlier but each time it comes up it seems like the thread and each entry takes away in some direction, with guite some volume, that at least for me, have made it impossible to understand what it is all about. Is it possible to describe, in a few lines, what the technical problem is in making the package build within the XEmacs Package Tree? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Straw man. It would result in binary packages where you had to use customize on some platforms to get the right result, not in "undistributable" binary packages. In fact, the AUCTeX team _did_ distribute those "undistributable" packages, to the satisfaction of the users. It is not "proof of concept". The generated packages work and are indistinguishable from those built by the XEmacs team (hypothetically assuming that the XEmacs team would build proper AUCTeX packages, that is). Which you do by calling ./configure make FTPDIR=/tmp/auctex TAG=11.84 tarball make FTPDIR=/tmp/auctex TAG=11.84 xemacs-package Then you have a completely built XEmacs package in /tmp/auctex, and an unpacked clean tarball in ./auctex-11.84. And that's just when pretending that we don't provide this XEmacs package already. Which is terribly hard, given that we distribute both tarball and XEmacs package. Let's see, that would be something like cd /tmp wget ftp://ftp.gnu.org/pub/gnu/auctex-11.84{,-pkg}.tar.gz rm -rf auctex-11.84 tar xzf auctex-11.84.tar.gz cd auctex-11.84 git-init-db git add . git commit -m tarball rm -rf * tar xzf ../auctex-11.84-pkg.tar.gz git add . git-diff --find-copies-harder --cached --stat -B -M -C HEAD defaulting to local storage area Committing initial tree 026d69106a07fd75b0d7452b3a944c3ddc6a22a4 etc/auctex/doc/preview.dvi | Bin {images => etc/auctex/images}/amstex.xpm | 0 {images => etc/auctex/images}/bibtex.xpm | 0 {images => etc/auctex/images}/dropdown.xpm | 0 {images => etc/auctex/images}/dvipdf.xpm | 0 {images => etc/auctex/images}/dvips.xpm | 0 {images => etc/auctex/images}/error.xpm | 0 {images => etc/auctex/images}/exec.xpm | 0 {images => etc/auctex/images}/execbibtex.xpm | 0 {images => etc/auctex/images}/execdvips.xpm | 0 {images => etc/auctex/images}/execerror.xpm | 0 {images => etc/auctex/images}/execpdftex.xpm | 0 {images => etc/auctex/images}/exectex.xpm | 0 {images => etc/auctex/images}/execviewdvi.xpm | 0 {images => etc/auctex/images}/execviewpdf.xpm | 0 {images => etc/auctex/images}/execviewps.xpm | 0 {images => etc/auctex/images}/gv.xpm | 0 {images => etc/auctex/images}/jumpdvi.xpm | 0 .../auctex/images}/ltx-symb-turn-off.xpm | 0 {images => etc/auctex/images}/ltx-symb-turn-on.xpm | 0 {images => etc/auctex/images}/pdftex.xpm | 0 {preview => etc/auctex}/images/prverr16.xpm | 0 {preview => etc/auctex}/images/prverr20.xpm | 0 {preview => etc/auctex}/images/prverr24.xbm | 0 {preview => etc/auctex}/images/prverr24.xpm | 0 {preview => etc/auctex}/images/prvtex-cap-up.xpm | 0 {preview => etc/auctex}/images/prvtex12.xbm | 0 {preview => etc/auctex}/images/prvtex12.xpm | 0 {preview => etc/auctex}/images/prvtex16.xbm | 0 {preview => etc/auctex}/images/prvtex16.xpm | 0 {preview => etc/auctex}/images/prvtex20.xpm | 0 {preview => etc/auctex}/images/prvtex24.xbm | 0 {preview => etc/auctex}/images/prvtex24.xpm | 0 {preview => etc/auctex}/images/prvwrk12.xpm | 0 {preview => etc/auctex}/images/prvwrk14.xpm | 0 {preview => etc/auctex}/images/prvwrk16.xpm | 0 {preview => etc/auctex}/images/prvwrk20.xpm | 0 {preview => etc/auctex}/images/prvwrk24.xbm | 0 {preview => etc/auctex}/images/prvwrk24.xpm | 0 {images => etc/auctex/images}/pspdf.xpm | 0 {images => etc/auctex/images}/sep.xpm | 0 {images => etc/auctex/images}/tex.xpm | 0 {images => etc/auctex/images}/view.xpm | 0 {images => etc/auctex/images}/viewdvi.xpm | 0 {images => etc/auctex/images}/viewpdf.xpm | 0 {images => etc/auctex/images}/viewps.xpm | 0 etc/auctex/latex/prauctex.cfg | 48 ++ etc/auctex/latex/prauctex.def | 61 +++ etc/auctex/latex/prcounters.def | 38 ++ etc/auctex/latex/preview.sty | 381 +++++++++++++++++++ etc/auctex/latex/prfootnotes.def | 28 + etc/auctex/latex/prlyx.def | 32 ++ etc/auctex/latex/prshowbox.def | 32 ++ etc/auctex/latex/prshowlabels.def | 67 +++ etc/auctex/latex/prtightpage.def | 120 ++++++ etc/auctex/latex/prtracingall.def | 30 + {style => etc/auctex/style}/.nosearch | 0 {style => etc/auctex/style}/MinionPro.el | 0 etc/auctex/style/MinionPro.elc | Bin {style => etc/auctex/style}/alltt.el | 0 etc/auctex/style/alltt.elc | Bin {style => etc/auctex/style}/alphanum.el | 0 etc/auctex/style/alphanum.elc | Bin {style => etc/auctex/style}/amsart.el | 0 etc/auctex/style/amsart.elc | Bin {style => etc/auctex/style}/amsbook.el | 0 etc/auctex/style/amsbook.elc | Bin {style => etc/auctex/style}/amsbsy.el | 0 etc/auctex/style/amsbsy.elc | Bin {style => etc/auctex/style}/amsmath.el | 0 etc/auctex/style/amsmath.elc | Bin {style => etc/auctex/style}/amsopn.el | 0 etc/auctex/style/amsopn.elc | Bin {style => etc/auctex/style}/amstex.el | 0 etc/auctex/style/amstex.elc | Bin {style => etc/auctex/style}/amstext.el | 0 etc/auctex/style/amstext.elc | Bin {style => etc/auctex/style}/amsthm.el | 0 etc/auctex/style/amsthm.elc | Bin {style => etc/auctex/style}/article.el | 0 etc/auctex/style/article.elc | Bin {style => etc/auctex/style}/babel.el | 0 etc/auctex/style/babel.elc | Bin {style => etc/auctex/style}/beamer.el | 0 etc/auctex/style/beamer.elc | Bin {style => etc/auctex/style}/book.el | 0 etc/auctex/style/book.elc | Bin {style => etc/auctex/style}/booktabs.el | 0 etc/auctex/style/booktabs.elc | Bin {style => etc/auctex/style}/captcont.el | 0 etc/auctex/style/captcont.elc | Bin {style => etc/auctex/style}/csquotes.el | 0 etc/auctex/style/csquotes.elc | Bin {style => etc/auctex/style}/czech.el | 0 etc/auctex/style/czech.elc | Bin {style => etc/auctex/style}/danish.el | 0 etc/auctex/style/danish.elc | Bin {style => etc/auctex/style}/dinbrief.el | 0 etc/auctex/style/dinbrief.elc | Bin {style => etc/auctex/style}/dk-bib.el | 0 etc/auctex/style/dk-bib.elc | Bin {style => etc/auctex/style}/dk.el | 0 etc/auctex/style/dk.elc | Bin {style => etc/auctex/style}/doc.el | 0 etc/auctex/style/doc.elc | Bin {style => etc/auctex/style}/dutch.el | 0 etc/auctex/style/dutch.elc | Bin {style => etc/auctex/style}/emp.el | 0 etc/auctex/style/emp.elc | Bin {style => etc/auctex/style}/epsf.el | 0 etc/auctex/style/epsf.elc | Bin {style => etc/auctex/style}/fancyref.el | 0 etc/auctex/style/fancyref.elc | Bin {style => etc/auctex/style}/foils.el | 0 etc/auctex/style/foils.elc | Bin {style => etc/auctex/style}/francais.el | 0 etc/auctex/style/francais.elc | Bin {style => etc/auctex/style}/frenchb.el | 0 etc/auctex/style/frenchb.elc | Bin {style => etc/auctex/style}/german.el | 0 etc/auctex/style/german.elc | Bin {style => etc/auctex/style}/graphics.el | 0 etc/auctex/style/graphics.elc | Bin {style => etc/auctex/style}/graphicx.el | 0 etc/auctex/style/graphicx.elc | Bin {style => etc/auctex/style}/harvard.el | 0 etc/auctex/style/harvard.elc | Bin {style => etc/auctex/style}/index.el | 0 etc/auctex/style/index.elc | Bin {style => etc/auctex/style}/inputenc.el | 0 etc/auctex/style/inputenc.elc | Bin {style => etc/auctex/style}/italian.el | 0 etc/auctex/style/italian.elc | Bin {style => etc/auctex/style}/j-article.el | 0 etc/auctex/style/j-article.elc | Bin {style => etc/auctex/style}/j-book.el | 0 etc/auctex/style/j-book.elc | Bin {style => etc/auctex/style}/j-report.el | 0 etc/auctex/style/j-report.elc | Bin {style => etc/auctex/style}/jarticle.el | 0 etc/auctex/style/jarticle.elc | Bin {style => etc/auctex/style}/jbook.el | 0 etc/auctex/style/jbook.elc | Bin {style => etc/auctex/style}/jreport.el | 0 etc/auctex/style/jreport.elc | Bin {style => etc/auctex/style}/jsarticle.el | 0 etc/auctex/style/jsarticle.elc | Bin {style => etc/auctex/style}/jsbook.el | 0 etc/auctex/style/jsbook.elc | Bin {style => etc/auctex/style}/jura.el | 0 etc/auctex/style/jura.elc | Bin {style => etc/auctex/style}/jurabib.el | 0 etc/auctex/style/jurabib.elc | Bin {style => etc/auctex/style}/latexinfo.el | 0 etc/auctex/style/latexinfo.elc | Bin {style => etc/auctex/style}/letter.el | 0 etc/auctex/style/letter.elc | Bin {style => etc/auctex/style}/listings.el | 0 etc/auctex/style/listings.elc | Bin {style => etc/auctex/style}/ltx-base.el | 0 etc/auctex/style/ltx-base.elc | Bin {style => etc/auctex/style}/ltxdoc.el | 0 etc/auctex/style/ltxdoc.elc | Bin {style => etc/auctex/style}/makeidx.el | 0 etc/auctex/style/makeidx.elc | Bin {style => etc/auctex/style}/mdwlist.el | 0 etc/auctex/style/mdwlist.elc | Bin {style => etc/auctex/style}/multind.el | 0 etc/auctex/style/multind.elc | Bin {style => etc/auctex/style}/natbib.el | 0 etc/auctex/style/natbib.elc | Bin {style => etc/auctex/style}/ngerman.el | 0 etc/auctex/style/ngerman.elc | Bin {style => etc/auctex/style}/nicefrac.el | 0 etc/auctex/style/nicefrac.elc | Bin {style => etc/auctex/style}/paralist.el | 0 etc/auctex/style/paralist.elc | Bin {style => etc/auctex/style}/pdfsync.el | 0 etc/auctex/style/pdfsync.elc | Bin {style => etc/auctex/style}/plfonts.el | 0 etc/auctex/style/plfonts.elc | Bin {style => etc/auctex/style}/plhb.el | 0 etc/auctex/style/plhb.elc | Bin {style => etc/auctex/style}/polish.el | 0 etc/auctex/style/polish.elc | Bin {style => etc/auctex/style}/polski.el | 0 etc/auctex/style/polski.elc | Bin {style => etc/auctex/style}/prosper.el | 0 etc/auctex/style/prosper.elc | Bin {style => etc/auctex/style}/psfig.el | 0 etc/auctex/style/psfig.elc | Bin {style => etc/auctex/style}/report.el | 0 etc/auctex/style/report.elc | Bin {style => etc/auctex/style}/scrartcl.el | 0 etc/auctex/style/scrartcl.elc | Bin {style => etc/auctex/style}/scrbase.el | 0 etc/auctex/style/scrbase.elc | Bin {style => etc/auctex/style}/scrbook.el | 0 etc/auctex/style/scrbook.elc | Bin {style => etc/auctex/style}/scrlttr2.el | 0 etc/auctex/style/scrlttr2.elc | Bin {style => etc/auctex/style}/scrpage2.el | 0 etc/auctex/style/scrpage2.elc | Bin {style => etc/auctex/style}/scrreprt.el | 0 etc/auctex/style/scrreprt.elc | Bin {style => etc/auctex/style}/slides.el | 0 etc/auctex/style/slides.elc | Bin {style => etc/auctex/style}/slovak.el | 0 etc/auctex/style/slovak.elc | Bin {style => etc/auctex/style}/subfigure.el | 0 etc/auctex/style/subfigure.elc | Bin {style => etc/auctex/style}/swedish.el | 0 etc/auctex/style/swedish.elc | Bin {style => etc/auctex/style}/units.el | 0 etc/auctex/style/units.elc | Bin {style => etc/auctex/style}/url.el | 0 etc/auctex/style/url.elc | Bin {style => etc/auctex/style}/varioref.el | 0 etc/auctex/style/varioref.elc | Bin {style => etc/auctex/style}/verbatim.el | 0 etc/auctex/style/verbatim.elc | Bin {style => etc/auctex/style}/virtex.el | 0 etc/auctex/style/virtex.elc | Bin {doc => info}/auctex.info | 0 {doc => info}/preview-latex.info | 0 lisp/auctex/_pkg.el | 5 lisp/auctex/auto-autoloads.el | 402 ++++++++++++++++++++ lisp/auctex/auto-autoloads.elc | Bin bib-cite.el => lisp/auctex/bib-cite.el | 0 lisp/auctex/bib-cite.elc | Bin context-en.el => lisp/auctex/context-en.el | 0 lisp/auctex/context-en.elc | Bin context-nl.el => lisp/auctex/context-nl.el | 0 lisp/auctex/context-nl.elc | Bin context.el => lisp/auctex/context.el | 0 lisp/auctex/context.elc | Bin lisp/auctex/custom-load.el | 47 ++ lisp/auctex/custom-load.elc | Bin font-latex.el => lisp/auctex/font-latex.el | 0 lisp/auctex/font-latex.elc | Bin latex.el => lisp/auctex/latex.el | 0 lisp/auctex/latex.elc | Bin multi-prompt.el => lisp/auctex/multi-prompt.el | 0 lisp/auctex/multi-prompt.elc | Bin {preview => lisp/auctex}/preview.el | 0 lisp/auctex/preview.elc | Bin {preview => lisp/auctex}/prv-xemacs.el | 0 lisp/auctex/prv-xemacs.elc | Bin tex-bar.el => lisp/auctex/tex-bar.el | 0 lisp/auctex/tex-bar.elc | Bin tex-buf.el => lisp/auctex/tex-buf.el | 0 lisp/auctex/tex-buf.elc | Bin tex-fold.el => lisp/auctex/tex-fold.el | 0 lisp/auctex/tex-fold.elc | Bin tex-font.el => lisp/auctex/tex-font.el | 0 lisp/auctex/tex-font.elc | Bin tex-fptex.el => lisp/auctex/tex-fptex.el | 0 lisp/auctex/tex-fptex.elc | Bin tex-info.el => lisp/auctex/tex-info.el | 0 lisp/auctex/tex-info.elc | Bin tex-jp.el => lisp/auctex/tex-jp.el | 0 lisp/auctex/tex-jp.elc | Bin tex-mik.el => lisp/auctex/tex-mik.el | 0 lisp/auctex/tex-mik.elc | Bin tex-style.el => lisp/auctex/tex-style.el | 0 lisp/auctex/tex-style.elc | Bin tex.el => lisp/auctex/tex.el | 0 lisp/auctex/tex.elc | Bin texmathp.el => lisp/auctex/texmathp.el | 0 lisp/auctex/texmathp.elc | Bin toolbar-x.el => lisp/auctex/toolbar-x.el | 0 lisp/auctex/toolbar-x.elc | Bin RELEASE => man/auctex/RELEASE | 0 {doc => man/auctex}/auctex.texi | 0 {doc => man/auctex}/changes.texi | 0 {doc => man/auctex}/copying.texi | 0 {doc => man/auctex}/faq.texi | 0 {doc => man/auctex}/fdl.texi | 0 {doc => man/auctex}/install.texi | 0 {doc => man/auctex}/intro.texi | 0 {doc => man/auctex}/macros.texi | 0 {doc => man/auctex}/preview-dtxdoc.texi | 0 {doc => man/auctex}/preview-faq.texi | 0 {doc => man/auctex}/preview-latex.texi | 0 {doc => man/auctex}/preview-problems.texi | 0 {doc => man/auctex}/preview-readme.texi | 0 {doc => man/auctex}/preview-todo.texi | 0 {doc => man/auctex}/quickstart.texi | 0 {doc => man/auctex}/tex-ref.tex | 0 {doc => man/auctex}/todo.texi | 0 {doc => man/auctex}/version.texi | 0 {doc => man/auctex}/wininstall.texi | 0 pkginfo/MANIFEST.auctex | 280 ++++++++++++++ 293 files changed, 1571 insertions(+), 0 deletions(-) Nonsense. It requires the AUCTeX distribution, the XEmacs package file, and a comparison tool. And actually, it does not really require even that. It suffices to take the finished XEmacs package distributed by AUCTeX, since that contains everything that is to end up in the XEmacs package from Sumo, in the right places. The rest is fluff. It is an illusion to imagine that taking the identical files from the source tarball instead of AUCTeX's binary XEmacs package is somehow going to make a legal difference: the copyrightable content is the same. In either case, XEmacs central decides that it needs not distribute the build infrastructure (whether from AUCTeX or from XEmacs) along with the binary package in order to comply with the GPL. The only part in the above file list that is harder than moving stuff around and using the normal XEmacs mechanisms (or taking a pregenerated file created by AUCTeX upstream mechanically without copyrightable content, with scripts that XEmacs central does not consider "source code" anyway and would not distribute), is to generate the unpacked files and documentation from preview.dtx (you need a basic LaTeX distro for that). And you need to do that only if you insist on ignoring the XEmacs package provided upstream. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David> [...] David> Which you do by calling David> ./configure David> make FTPDIR=/tmp/auctex TAG=11.84 tarball David> make FTPDIR=/tmp/auctex TAG=11.84 xemacs-package David> Then you have a completely built XEmacs package in /tmp/auctex, David> and an unpacked clean tarball in ./auctex-11.84. Are you suggesting that this would be a good starting point for inclusion in the XEmacs Package Tree? David> [...] David> And actually, it does not really require even that. It David> suffices to take the finished XEmacs package distributed by David> AUCTeX, since that contains everything that is to end up in the David> XEmacs package from Sumo, in the right places. The build procedure designed by the AUCTeX team is quite likely perfect for its job, and built against the right version of the SUMO package (there is an integration issue here right!?) it will be fine, but that doesn't make me understand a bit what is the problem in making it build within the XEmacs Package Tree. David> It is an illusion to imagine that taking the identical files David> from the source tarball instead of AUCTeX's binary XEmacs David> package is somehow going to make a legal difference: the David> copyrightable content is the same. In either case, XEmacs David> central decides that it needs not distribute the build David> infrastructure (whether from AUCTeX or from XEmacs) along with David> the binary package in order to comply with the GPL. I wasn't aware that there are legal issues here. Please explain? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: The XEmacs package system does not support external build procedures. That's all there is to it. I don't like it, but I don't have the time or skills to fix it. The package system contains a set of Makefiles which control compiling the Lisp files in a "clean" environment, building documentation, installing either to the ultimate destination or to the equivalent of a DESTDIR, and bundling up such an installation in a tarball. There is no need for invoking a separate build procedure. Nobody ever claimed that there was a legal difference. Simply that David's claims about what must be distributed in a derivative of AUCTeX are invalid. David's claim is that to comply with the GPL, we must distribute the packaging system with every package, citing the part of the GPL that says "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." I disagree with David's claim. I believe that the installed package is a perfectly good source package as defined by the GPL. It is not the original package, of course; it is a derivative. The GPL explicitly permits making derivatives. That's so even if they lack some of the convenience, or even the functionality, of the original. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: What a lot of people would like is a way to take a third party package and wrap it in XEmacs package clothing without doing any quality control against other XEmacs packages. In many cases, that will work just fine, either because the package has no important dependencies on other packages, or because the upstream project does careful testing itself. But: Precisely. Inclusion of a package in the XEmacs package tree is (a) a certification that XEmacs developers have looked at it and (b) built it in the context of the XEmacs packages, and (c) a promise that we'll at least look at bug reports against it, especially those involving interaction with other packages. It's not a claim that we do a better job than upstream; it's a claim that we did *something*. We can't make that claim if we simply redistribute a pre-built tarball. "Support" is a strong word for what we have the manpower to do at the moment:-(, but I see no argument at all for including 3rd party packages sight unseen. I do see an argument for making it easier to access 3rd party download sites that provide a package containing XEmacs-style metadata which unpacks into the installed package tree appropriately. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Let me try to briefly set the record straight as to what I believe are the technical facts relevant to determining whether XEmacs packages are conformant to the GPL requirement to distribute source. of each package.[1] The first derivative version is distributed only as source (and therefore has no problem with that requirement), as part of the collective work known as the "XEmacs package CVS repository." This is the preferred version for development activity. The second version of each package, which is a separate derivative Work (see footnote 1), is a *binary-with-source distribution* that has the following properties: 1. The files that need processing (ie, Lisp) are in the right place. 2. The objects produced by processing them (ie, the .elcs) automatically are installed in the right place (ie, next to the corresponding .el). The required processor is part of the core XEmacs binary and its associated Lisp. 3. The auto-autoloads.el file is produced by a processor which is part of the core XEmacs binary and its associated Lisp. 4. Other data files are in the right place; they can be edited to the user's taste in place. 5. We provide prebuilt auto-autoloads and .elcs for convenience. There is no need for a Makefile, because everything that needs to be edited or rebuilt is already in place. If a new entry point has been added, M-x update-autoload-files rebuilds the auto-autoloads file. Then M-x byte-recompile-directory will do everything that is needed. Installing other than to an installed XEmacs package tree is not required; our *binary-with-source distribution* is restricted by design to use in that context. Installing, other than by unpacking the tarball, is not required; our *binary-with-source distribution* is designed to be unpacked in the installation destination. Creating the tarball, whether upstream-style or an XEmacs *-pkg.tar.gz, is not required, because the tarball is the *medium*, not the *message*. If you want any of those features (and they are all desirable, of course!), you would be well-advised to use either the XEmacs CVS repository version or the upstream AUCTeX version. In other words, you have to look at what we actually *do* distribute as a "binary-with-source" distribution to see whether it really is necessary to distribute Makefiles etc for it. The GPL doesn't say "you must provide all the infrastructure needed to set up as a competing distributor". The GPL doesn't say "you must provide a source package in the same format that you received it". The GPL doesn't say "you must provide sources that can be used to build all the configurations imaginable." It says "you must provide the sources for the executable you distribute, as well as the scripts used to build it." We do. It happens that AFAICS no scripts are needed to build the executable. Furthermore, in practice *no scripts are used* to build from the "binary with source" distribution. I do edit and rebuild packages in the installed tree frequently, and have never felt a need for a script (with the single exception of rather old versions of VM---for which we *do* provide the Makefile!) It's possible that the generic description above doesn't apply to the AUCTeX package in particular, but I've seen no specific description of such features of AUCTeX. It is true that a script is used in building the distribution, and therefore the specific instance of the executable in the tarball. The literal interpretation of "scripts used to build it" as meaning "in the physical history of the distributed executable" is plausible, of course. But I think the interpretation of "used" as hypothetical (ie, "scripts used to build it [in case you had modified it]") is more in keeping with the intent and spirit of the rest of the GPL, which tries to give maximum freedom for creating derivative works attuned to user needs, without sacrificing those users' freedoms to "change the software or use pieces of it in new free programs". Footnotes: [1] This is trivial. If you change one comma, you have produced a derivative work. So, actually, we are trivally able to distribute hundreds of different derivative versions of AUCTeX, at least two for every patch in the CVS repository. To be pedantically precise, I should say not "two versions" but "two classes of versions". _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Wed, Jan 24, 2007 at 12:58:05PM +0100, David Kastrup wrote: The XEmacs CVS package repository is the preferred form for the sources for modification. Everybody has access to the XEmacs CVS package repository. Pserver *is* a medium customarily used for software interchange, as sourceforge proves. Other distribution methods for the sources are just for convenience. I kinda doubt there is any significant legal difference between the ftp and pserver protocols. Amusingly enough, some people argue that the GPL source distribution of anything that is kept under a SCM system should be done with the complete SCM history included, because the source alone does not meet the "preferred form" criteria. BTW Stephen, is there any real reason not to include the two files the crybaby is having a fit over, even if they're pretty much unusable outside of a CVS context from what I understand? They can have some value as an example, I guess. OG. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Olivier Galibert wrote: It's not clear that a CVS repository and an FTP server running on the same host are even "the same place". And, AFAICT, cvs.xemacs.org and ftp.xemacs.org aren't even on the same network. Furthermore, when the code is available via an FTP mirror, who is distributiing it? I.e. who is the "you" mentioned throughout the GPL? The XEmacs developers, or the admin of the FTP server? If it's the latter, they aren't providing anyone with access to the CVS repository, so they need to provide the "complete source code". IOW, even if ftp://ftp.xemacs.org and :pserver:cvs＠cvs.xemacs.org are considered "the same place"[1] in the context of: If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. other FTP mirrors arguably aren't "the same place". The issue is even more acute for someone distributing CDs of what appears to be freely-redistributable souce code taken from the FTP site. Given that the XEmacs "binary" packages are so close to being "the complete source code" (they may even be so; IANAL, and, AFAIK, neither is David), adding those files would mean that access to the CVS repository should be a non-issue. Personally, I'd suggest ensuring that one can rely solely upon the argument that the binary packages really do consitute the complete source code as defined by the GPL, without feeling any need to use the "if it isn't, you can get the rest from CVS" argument. -- Glynn Clements <glynn(a)gclements.plus.com&gt; _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Glynn Clements writes: IANAL, but my feeling is that different protocols are different places.[1] I would vocally :-) oppose XEmacs relying on the argument that on the Internet all commonly used media amount to the same place. That's not in the spirit of trying to conform. First, those files are definitely insufficient. AFAICT David is referring to the Makefile and XEmacs.rules (plus "template files," by which I suppose he means package-info.in). But XEmacs.rules calls several Lisp files as well as including at least the Local.rules Makefile. Furthermore, in the case of AUCTeX, the xemacs-base package is loaded from its source location at build time. I don't see any point in a source package which doesn't include those prerequisites, which vary by individual package, although it's not legally required AFAICS (the xemacs-base source tarball would be available in the same place). My tentative conclusion is that the (comparatively ;-) sane thing to do is to bundle up the whole source tree and call that the "complete source", which can be used to build a variety of packages. That cannot be done if the Makefiles are required by the GPL, because they are non-functional in the installed context. (Remember, in the source tree, auctex is a child of xemacs-packages, whereas in the installed tree it is always a grandchild.) The GPL doesn't require "documentation of the build process", it requires "the scripts *used* to build the executable." Adopting the "historical" interpretation of "used" would be unacceptable to me if it's merely a way to dodge our responsibility to provide full, working source in "the same place". I conclude that if the CVS tree Makefiles are part of the complete source, a separate source package should be constructed. Footnotes: [1] I consider this a bug in the GPL. The Internet is an ether, so as long as the client is easily available, and CVS is, a CVS server and a FTP server on a different planet are "the same place". The GPL should require that the source be available in a publically accessible place, for no access charge, and that place be a well-advertised URN---note the "N". In fact, IIRC that's what draft GPLv3 does in effect. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Thu, Jan 25, 2007 at 12:09:36PM +0900, Stephen J. Turnbull wrote: IANAL either, but since we're having fun, let me expose my feelings: the "place" is defined by the DNS. "xemacs.org", is our case, has recognition. Everything under that, whatever the actual physical implementation is, is considered part of the XEmacs (lack of-) organization. OTOH, ftp, http, cvs (pserver), svn, etc are mediums. When f.i. you grab a tar file from xemacs.org you tend to give the same level of trust to it no matter whether you got it from ftp or http. As for the AUCTeX problem, legalities aside, it looks like we're distributing it against the wishes of (one of|the) main maintainer. Shouldn't we just stop? OG. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Olivier Galibert writes: Hey, that applies to distributing XEmacs itself. Shouldn't we just stop? I don't think so. AUCTeX is free software. Uwe Brauer, who maintains the XEmacs package of AUCTeX, values an XEmacs package enough to do the work and put up with both me and David Kastrup (who has publically insulted Uwe on a number of occasions). I personally use the XEmacs package of AUCTeX because it's all I need to use. That proves that some XEmacs users and contributors get positive value from the package version. As we've seen with ESS, users notice when a package disappears. Some are just as happy to go upstream, but others experience a noticeable inconvenience. I suspect that we'd see a lot more of the latter with AUCTeX than we did with ESS, though I can't prove it. If Uwe decides to quit, then I think it's reasonable to consider dropping AUCTeX from the XEmacs packages distribution (but not yet a no-brainer). Or if *you* have a different opinion about what is good for XEmacs users, we should discuss that. But "David Kastrup doesn't like it" is a non-starter for me. David has made it plain that XEmacs goals are none of his business, and that he believe his only duty to XEmacs is to tell us what our users need. I see no reason to do anything other than reciprocate in not caring about David's goals for AUCTeX. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

* David Kastrup (2007-01-27) writes: Since the version distributed with the XEmacs package collection is unsupported upstream, one could conclude that the XEmacs project is taking care of support for that version. In that case you should at least add a disclaimer of the different support address and change the bug reporting address. I don't remember an insult either. My experience with the XEmacs lists obviously differs from yours. I haven't got an answer to some of the bug reports and inquiries I've sent, but when I got an answer, discussion was mostly helpful and constructive. Of course, there were also cases which could not be dealt with due to lack of resources. Apart from that I don't really understand why the XEmacs project is distributing an outdated version of AUCTeX (or any other package for that matter). It sheds a bad light on their package system and renders it useless to some extent. In addition it leads to the constant stream of unpleasent discussions we've seen around the AUCTeX package. And it exhibits ignorance towards upstream developers who have to deal with reports of bugs which have long been fixed in more recent upstream versions. So the XEmacs project could _at least_ change the support addresses. If they feel they cannot provide sufficient support for a package they distribute as an outdated version, they should consider refraining from distributing it. The situation would be a bit better if the XEmacs package system allowed for the inclusion of additional locations for package download similar to something like apt. Then the argument regarding the quality of externally built packages would be moot because users would know that the package is not provided by the XEmacs project. But implementing such a feature is likely not economically sensible because I doubt there are many XEmacs packages built outside of the XEmacs project. Regarding the removal of XEmacs support I think we should do this only if we consider the interest of XEmacs _users_ not significant enough to justify the work invested in compatibility with XEmacs. I don't consider the ignorance of the XEmacs project towards AUCTeX enough of a reason to justify a removal of XEmacs compatibility. As a side note: Once I'll have checked in my changes to font locking we'll even get multi-line font locking in XEmacs which will get rid of some inabilities of XEmacs currently documented as bugs in our manual. So at least in this respect we are heading in the opposite direction of your proposal. -- Ralf _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Ralf Angeli writes: I've already announced my intention to do that. I gather you're not aware of that? However, the issue of the addresses was discussed with Uwe Brauer when he volunteered, who indicated at the time that we should point our auctex-* aliases at AUCTeX. That may have been an uninformed decision, but at the time we believe that it would be possible to have an up-to-date package without too much trouble. However, if this is so annoying to you, there must be lots of them. I'm curious, why aren't those users coming to XEmacs? Don't you tell them what the right place to report bugs is? Or what? What don't you understand? That users like the convenience of the packages for updates when available, and of the SUMOs for initial installation? Well, let me tell you: users like the convenience of the packages for updates when available, and of the SUMOs for initial installation. Or don't you understand that our resources for updates are finite and mostly user-contributed, thus there are lags? Well, let me tell you: our resources for updates are finite and mostly user-contributed, thus there are lags. I'm really tired of repeating those facts. Yes, I know that this thread just started on AUCTeX. But surely you can see the 13 References that preceded your post as well as I can? Nor is it like Debian stable or even Fedora core manages to keep all of its packages up to the minute. Or GNU Emacs, for that matter, except when it can absorb an upstream package so that the Emacs version *is* the current version by definition. *All* distros make this compromise. As for AUCTeX in particular, you quoted the reason already: In addition, I'm happy enough with the AUCTeX we've got for my own use. If so, why aren't we hearing that from our users? What we hear from the users is that they like packages, and the ones who want an up-to-date AUCTeX get it from AUCTeX. Win-win, as far as I can see. The fact is that the only people who complain about the XEmacs package system in general are upstream package developers. Of course users whose favorite package is out-of-date report it as a bug, but they rarely get very upset when offered the choice of maintaining the XEmacs package or maintaining their own installation of upstream by hand. There are some clumsy aspects, those are bugs too---but that doesn't stop most users from using the package system. It doesn't. The unpleasantness is entirely due to personality conflicts. The ESS package has very similar technical issues, and the current maintainer there decided to withdraw the package. Of course things were a little tense because of the goal conflict, but basically the relationship has been amicable and the discussions productive. And there are others in that project who disagree with the current maintainer; I'm sure something will be worked out when resources become available. That happened a while ago, but a related thread happened this week, too. AUCTeX doesn't have that option because AUCTeX refuses to help with the XEmacs package (as we define it; I know you have something that unpacks into the same places, but it doesn't serve *our* goals), and AFAIK the XEmacs maintainer wishes to keep trying to update the AUCTeX package. Someday we'll succeed. Please. AFAI knew, Uwe was considered part of the AUCTeX project. He didn't ask for a change, so the aliases didn't change. *You* didn't explicitly ask for a change, either. Not that I know of. Don't say it should be obvious; it wasn't, especially not in the midst of the firestorm that David enters the XEmacs lists with almost every time. So, I've changed the aliases. Fixing addresses in the package itself will have to wait a day or so. *We get no bug reports from users.* It's as simple as that. If and when we start getting bug reports, there will be something to consider. We've had that forever. It's clumsy, you can only have one site active at a time AFAICT, and the interface for users to add sites is undocumented (AFAIK). I've already proposed fixing that, too, in this thread. It's technically not that hard, I think. A major overhaul of the package UI almost happened 3 years ago, but Steve Youngs wanted to do it his way, then it never got done. I'm sure several would be, actually. VM already is. x-symbol would be (unless upstream has abandoned it). If the facility were available, I suspect several projects would want to do it; it's not like the typical DESTDIR install would be very hard. One problem is that that kind of sensible, everybody-wins suggestion has rarely been made. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Ralf Angeli writes: Hm. Sounds to me like the process is working just about like *we* want it to. They try the package version, they want something more, they ask for it, they get it. Those who don't need more don't say anything, they just are happy. I realize that doesn't meet *your* needs or expectations in any way. I'll get in touch with Uwe and see what he wants to do/can do about updating or abandoning the XEmacs packaged version. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: 1. We want distributions containing binaries to be built in the context of the versions that we have in package CVS, so that we can be very sure that they will work in vanilla user installations. 2. We want something better than Fundamental mode to be available at zero extra effort to our users. (Ie, they have to install xemacs-base; if they do so by installing the SUMO, they're done.) 3. We want the development to remain in the hands of the upstream developers, and XEmacs package maintenance to be contributed by non-core-developers, wherever possible. 4. We prefer recent versions to older ones. Quite definitely, in that order. 1 and 2 are automatically accomplished by the current system. 3 and 4 are implemented as possible, based on user requests and time contributions by package maintainers and upstream and XEmacs developers. Speaking for myself, but AFAIK this is a reasonable reflection of a consensus of the XEmacs Review Board. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Uwe Brauer <oub(a)mat.ucm.es&gt; writes: It would remove quite a bit of tension. It does not address the sidetrack of the thread where I have been called a bully, crybaby, somebody threatening with legal action (even though I pointed out repeatedly that I am not the copyright holder of AUCTeX) and whatever else, since that is not concerned with AUCTeX in particular but rather the general structure of XEmacs packages. If there was _any_ interest in getting my concerns about that addressed, I could offer to phrase a request to the copyright clerk at the FSF and have it double-checked by Stephen before sending it off, or Stephen could do this himself. I don't think that this offer could possibly be considered a threat unless parties here are not as utterly convinced of my lunacy as they put it, since it would place the question out of my and into competent hands. Whatever. That's a different problem (or non-problem, as people would have it). With regard to the state of AUCTeX redistribution by XEmacs, a successful upgrade certainly be the best option for now. It is to be hoped, however, that future synchs would work better. Actually not: preview-latex is not distributed separately anymore, so as opposed to the old 11.55, people would no longer have the option to install manually what the XEmacs package system omitted. Speaking for myself personally, I have to say no: the interest of the AUCTeX team is still rather with helping rather than abandoning XEmacs users. Of course, it is annoying to get reports for ancient packages, but the solution is telling people to upgrade, not leaving them in the dark. I disagree here. People wanting to use AUCTeX will find how to come by it. Note that AUCTeX has not been activated by default in the standard XEmacs setup IIRC because people might prefer the "builtin" TeX mode. At least in the AUCTeX's package, this has been changed and we have added a way to turn AUCTeX off if one so desires. But the fact remains that historically people did not get AUCTeX activated without asking for it in their .emacs file explicitly, and so the added value of a preinstalled installation for the user not bothering about anything has always been questionable, to say the least. -- David Kastrup _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Olivier Galibert writes: I personally think that's a reasonable definition. Indeed, preferable. But what about RMS and Eben Moglen? The GPL clearly intends to promote source distribution. Binary distribution is a non-issue. As a concession to convenience, it permits prebuilt binaries and separate distribution of binaries and sources. However, the wording indicates that it wants to force the user to make a conscious decision to "throw away" the source. I conclude that the "same protocol" interpretation of the current wording implements the intent of the author, and so is not a bug. (Yes, that is a reversal of my previous claim. Sleep improves my ability to think. :^) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: sjt> I conclude that if the CVS tree Makefiles are part of the complete sjt> source, a separate source package should be constructed. Sure, but for me that's a non-starter. If you succeed in convincing me that the process described below does not satisfy the GPL, then either the project will get source packages that do satisfy the GPL in letter and spirit, *batteries included*, or it will stop distributing binary packages, or I will leave the project. However, I believe that our "binary" packages satisfy both the letter and spirit of the GPL concerning source. Specifically, I personally modify packages in place, rebuild them, and continue work, and we often get patches from users who apparently do the same. I believe that modification and rebuild of the binary received is all that the GPL asks of a source distribution. This requires a bare minimum of effort: M-x find-library, C-x C-s, M-x byte-compile-and-load-file, M-x update-autoload-file, M-x byte-compile-file RET auto-autoloads.el. No scripts are used, therefore no script need be distributed. Installation is done by "tar x", not by "make install". As for "preferred form", it clearly refers not to the organization of the files into directories or the presence of Makefiles, but to the language of the content of files that *are* present. The only remaining issue are the package-info files, but they have no user-servicable parts. Of course if the user *wants* to change them, they're just Lisp files, and he can. That is exactly what I would do if (for example) I wanted to tag a locally-modified installed package as modified. I would *not* do that in package-info.in! I see no reason to suppose that the package-info.in form is any more "preferred" *here*. (In the context of the CVS version it is, but that is a different Work.) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Henry S. Thompson writes: No. We have communicated about this issue ad nauseum, and it comes down to a conflict over quality control systems. The XEmacs package system doesn't support, and doesn't plan to support, building outside of the package tree. This policy makes the maintenance of a large collection of packages with minimal resources feasible. AUCTeX doesn't intend to support building inside of the package tree. That makes maintenance of a large multiplatform package easier. There are a couple of people interested in bridging the gap, but progress is slow. For users, the basic rule is that if you are at all likely to want support from the AUCTeX developers, use the AUCTeX project's package. If your natural reaction to any bug encountered while using XEmacs is to write to XEmacs Beta, and you are unlikely to even look up what new features AUCTeX provides in v11.84 over and above v11.55 (the version in the XEmacs packages), you may use the package distributed by XEmacs. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

ht(a)inf.ed.ac.uk (Henry S. Thompson) writes: Feel free to suggest changes to the text that I have added above the AUCTeX release announcement if you feel that it is in any manner misleading, incorrect or irrelevant. I was of the opinion that it properly presented the current state of affairs as far as it is relevant to AUCTeX/XEmacs users without being inflammatory. Yes, it did lead to the "Dead Parrot Sketch" again, but I don't see how I could have prevented this while retaining the information relevant to people wanting to use AUCTeX under XEmacs. Proposals for a better wording are welcome. It does not appear that the necessity for conveying this information will go away anytime soon. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta