* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. [not found] <E1TfF2V-0003Gn-No@vcs.savannah.gnu.org> @ 2012-12-03 20:40 ` Stefan Monnier 2012-12-04 7:29 ` Tassilo Horn 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2012-12-03 20:40 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel I have some questions about copyright in your latest AUCTeX update. What is the copyright status of the following new files: - psfig.el, epsf.el, latexinfo.el (Gemis is not found in copyright.list)? - dinbrief.el (Werner Fink is not found in copyright.list)? - prosper.el (Philippe Lord has papers on file for Emacs, but Nevin Kapur only for Gnus)? Also why change copyright from FSF to Hidenobu Nabetani in tex-jp.el: -;; Copyright (C) 1999, 2001-2007, 2012 Free Software Foundation, Inc. +;; Copyright (C) 1999, 2001 Hidenobu Nabetani <nabe@debian.or.jp> +;; Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation -- Stefan "Who just shortened some copyright year ranges in `elpa'" ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-03 20:40 ` [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release Stefan Monnier @ 2012-12-04 7:29 ` Tassilo Horn 2012-12-04 14:50 ` Stefan Monnier 0 siblings, 1 reply; 15+ messages in thread From: Tassilo Horn @ 2012-12-04 7:29 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > I have some questions about copyright in your latest AUCTeX update. > > What is the copyright status of the following new files: > > - psfig.el, epsf.el, latexinfo.el (Gemis is not found in copyright.list)? > - dinbrief.el (Werner Fink is not found in copyright.list)? > - prosper.el (Philippe Lord has papers on file for Emacs, but Nevin > Kapur only for Gnus)? Oh, sorry. I'll investigate on those and try to get the CAs. I didn't check the status for them, because we only accept contributions including CAs nowadays, but maybe those are old leftovers... For the time being, I've delete the files from the elpa branch. > Also why change copyright from FSF to Hidenobu Nabetani in tex-jp.el: > > -;; Copyright (C) 1999, 2001-2007, 2012 Free Software Foundation, Inc. > +;; Copyright (C) 1999, 2001 Hidenobu Nabetani <nabe@debian.or.jp> > +;; Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation > > -- Stefan "Who just shortened some copyright year ranges in `elpa'" I didn't really merge elpa/packages/auctex with the auctex CVS repository (which is not so easy because the directory layout differs) but just copied over the files from the new auctex release tarball. But now I'm going to merge your copyright header changes back to the auctex CVS. Bye, Tassilo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-04 7:29 ` Tassilo Horn @ 2012-12-04 14:50 ` Stefan Monnier 2012-12-04 20:34 ` Tassilo Horn 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2012-12-04 14:50 UTC (permalink / raw) To: emacs-devel > I didn't really merge elpa/packages/auctex with the auctex CVS > repository (which is not so easy because the directory layout differs) > but just copied over the files from the new auctex release tarball. But > now I'm going to merge your copyright header changes back to the auctex > CVS. Why still use the CVS repository? It seems more trouble than anything. Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-04 14:50 ` Stefan Monnier @ 2012-12-04 20:34 ` Tassilo Horn 2012-12-04 21:26 ` Stefan Monnier 0 siblings, 1 reply; 15+ messages in thread From: Tassilo Horn @ 2012-12-04 20:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I didn't really merge elpa/packages/auctex with the auctex CVS >> repository (which is not so easy because the directory layout >> differs) but just copied over the files from the new auctex release >> tarball. But now I'm going to merge your copyright header changes >> back to the auctex CVS. > > Why still use the CVS repository? It seems more trouble than > anything. Do you have a better idea? We are planning to migrate to some DVCS anytime soon, but since AUCTeX is expected to work with all Emacs versions >= 21.x plus XEmacs >= 21.4.x, there's no way to develop it only as a part of emacs in its bzr repo, although that would be very nice from a maintenance point of view. Bye, Tassilo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-04 20:34 ` Tassilo Horn @ 2012-12-04 21:26 ` Stefan Monnier 2012-12-05 14:06 ` Tassilo Horn 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2012-12-04 21:26 UTC (permalink / raw) To: emacs-devel > Do you have a better idea? Use elpa/packages/auctex as the official upstream. > We are planning to migrate to some DVCS anytime soon, but since AUCTeX > is expected to work with all Emacs versions >= 21.x plus XEmacs >= > 21.4.x, there's no way to develop it only as a part of emacs in its > bzr repo, although that would be very nice from a maintenance point > of view. I don't see what prevents it. AFAICT it still contains all the backward compatibility code that's in CVS and nobody asked to remove it. If there are a couple more xemacs-specific files, I have no objection to you adding them. The only remaining problem I can imagine is for those few files which aren't FSF-copyright and hence aren't in the ELPA package, but IIUC these are obsoletish and could just be dropped (noone complained about them missing from the ELPA version). Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-04 21:26 ` Stefan Monnier @ 2012-12-05 14:06 ` Tassilo Horn 2012-12-05 14:24 ` David Kastrup 2012-12-08 11:25 ` [AUCTeX-devel] " Ralf Angeli 0 siblings, 2 replies; 15+ messages in thread From: Tassilo Horn @ 2012-12-05 14:06 UTC (permalink / raw) To: Stefan Monnier; +Cc: auctex-devel, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: Hi Stefan, I've added the auctex-devel list to the Cc. >> Do you have a better idea? > > Use elpa/packages/auctex as the official upstream. > >> We are planning to migrate to some DVCS anytime soon, but since >> AUCTeX is expected to work with all Emacs versions >= 21.x plus >> XEmacs >= 21.4.x, there's no way to develop it only as a part of >> emacs in its bzr repo, although that would be very nice from a >> maintenance point of view. > > I don't see what prevents it. AFAICT it still contains all the > backward compatibility code that's in CVS and nobody asked to remove > it. If there are a couple more xemacs-specific files, I have no > objection to you adding them. I'd welcome this but David and Ralf are more qualified to judge about feasibility. Especially, there's much complexity in auctex's build system in order to compile XEmacs packages, and that's a bit more than just an auctex-compat.el. > The only remaining problem I can imagine is for those few files which > aren't FSF-copyright and hence aren't in the ELPA package, but IIUC > these are obsoletish and could just be dropped (noone complained about > them missing from the ELPA version). Yes, these 5 or 6 files are only addons for some special latex styles. They are not important for auctex, and they could be dropped or easily rewritten by someone else with CA by just looking at the corresponding latex style but not the current code. Bye, Tassilo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-05 14:06 ` Tassilo Horn @ 2012-12-05 14:24 ` David Kastrup 2012-12-05 14:39 ` [AUCTeX-devel] " Uwe Brauer ` (2 more replies) 2012-12-08 11:25 ` [AUCTeX-devel] " Ralf Angeli 1 sibling, 3 replies; 15+ messages in thread From: David Kastrup @ 2012-12-05 14:24 UTC (permalink / raw) To: Stefan Monnier; +Cc: auctex-devel, emacs-devel Tassilo Horn <tsdh@gnu.org> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > > Hi Stefan, > > I've added the auctex-devel list to the Cc. > >>> Do you have a better idea? >> >> Use elpa/packages/auctex as the official upstream. >> >>> We are planning to migrate to some DVCS anytime soon, but since >>> AUCTeX is expected to work with all Emacs versions >= 21.x plus >>> XEmacs >= 21.4.x, there's no way to develop it only as a part of >>> emacs in its bzr repo, although that would be very nice from a >>> maintenance point of view. >> >> I don't see what prevents it. AFAICT it still contains all the >> backward compatibility code that's in CVS and nobody asked to remove >> it. If there are a couple more xemacs-specific files, I have no >> objection to you adding them. > > I'd welcome this but David and Ralf are more qualified to judge about > feasibility. Especially, there's much complexity in auctex's build > system in order to compile XEmacs packages, and that's a bit more than > just an auctex-compat.el. The XEmacs package building is sort of an aggravation. An XEmacs package contains all necessary files plus info source files in a rigid directory layout, possibly not unsimilar to what ELPA or any other package would do. Now XEmacs will only distribute package files that have been assembled by XEmacs tools in the XEmacs package tree. So the XEmacs packages that AUCTeX provides will work fine, but you'll have to find, download and install them manually instead of relying on the XEmacs packaging system. What will be provided in the XEmacs package repositories consequently is something massaged manually to the necessary layout, commonly with mistakes and several years behind. So it is not clear to me who the customers for the XEmacs packages we compile actually are. Smart people, most likely. XEmacs itself boycotts our packaging efforts since we don't arrive at the right layout in the canonical way. The XEmacs compatibility code in the Lisp files itself is peanuts in comparison. No point in removing that as far as I can see. However, preview-latex has a somewhat more extensive compatibility setup. It would be arguable not to place the prv-xemacs.el files in the ELPA packaging at least. Removing it from the source distribution would be seriously unfair since it is technically complex enough that starting it from scratch would be quite hard: that would be several man-months at least from an experienced XEmacs programmer, and there are none as far as I can see interested in AUCTeX. >> The only remaining problem I can imagine is for those few files which >> aren't FSF-copyright and hence aren't in the ELPA package, but IIUC >> these are obsoletish and could just be dropped (noone complained >> about them missing from the ELPA version). > > Yes, these 5 or 6 files are only addons for some special latex styles. > They are not important for auctex, and they could be dropped or easily > rewritten by someone else with CA by just looking at the corresponding > latex style but not the current code. Also possible to go assignment-shopping for them once again. -- David Kastrup ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [AUCTeX-devel] [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-05 14:24 ` David Kastrup @ 2012-12-05 14:39 ` Uwe Brauer 2012-12-05 15:14 ` Stefan Monnier 2012-12-15 14:08 ` Tassilo Horn 2 siblings, 0 replies; 15+ messages in thread From: Uwe Brauer @ 2012-12-05 14:39 UTC (permalink / raw) To: David Kastrup; +Cc: auctex-devel, xemacs-beta, Stefan Monnier, emacs-devel >> On Wed, 05 Dec 2012 15:24:50 +0100, David Kastrup <dak@gnu.org> wrote: > Tassilo Horn <tsdh@gnu.org> writes: [snip] > Now XEmacs will only distribute package files that have been assembled > by XEmacs tools in the XEmacs package tree. This is correct. I wish it were different, that there existed a debian-like-alien tool which allowed to convert one package into another one, like deb-->rpm > So the XEmacs packages that AUCTeX provides will work > fine, but you'll have to find, download and install > them manually instead of relying on the XEmacs > packaging system. You can unpack it in ~/.xemacs/packages or in prefix/xemacs/site-packages > What will be provided in the XEmacs package > repositories consequently is something massaged > manually to the necessary layout, commonly with > mistakes and several years behind. Well if their package manager were faster it should be a question of days not years :'( [snip] > The XEmacs compatibility code in the Lisp files itself is peanuts in > comparison. No point in removing that as far as I can see. However, > preview-latex has a somewhat more extensive compatibility setup. It > would be arguable not to place the prv-xemacs.el files in the ELPA > packaging at least. That is your call to make. > Removing it from the source distribution would be > seriously unfair since it is technically complex enough that starting it > from scratch would be quite hard: that would be several man-months at > least from an experienced XEmacs programmer, and there are none as far > as I can see interested in AUCTeX. Yes, please, do *not* remove it, that would be real nightmare for Xemacs users. Uwe Brauer ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-05 14:24 ` David Kastrup 2012-12-05 14:39 ` [AUCTeX-devel] " Uwe Brauer @ 2012-12-05 15:14 ` Stefan Monnier 2012-12-05 16:46 ` David Kastrup 2012-12-06 1:46 ` Stephen J. Turnbull 2012-12-15 14:08 ` Tassilo Horn 2 siblings, 2 replies; 15+ messages in thread From: Stefan Monnier @ 2012-12-05 15:14 UTC (permalink / raw) To: David Kastrup; +Cc: auctex-devel, emacs-devel > The XEmacs package building is sort of an aggravation. An XEmacs > package contains all necessary files plus info source files in a rigid > directory layout, possibly not unsimilar to what ELPA or any other > package would do. Can you describe how does the XEmacs-package-building relates to the VCS repository? Is it that the CVS layout was chosen specifically to match the XEmacs package requirements? Are those requirements incompatible with the ones for ELPA packages? > So it is not clear to me who the customers for the XEmacs packages we > compile actually are. I'll let the AUCTeX maintainer(s) decide whether it's important to support this. > However, preview-latex has a somewhat more extensive compatibility > setup. It would be arguable not to place the prv-xemacs.el files in > the ELPA packaging at least. If a file is in `elpa/packages/auctex' then it will be in the ELPA package (which is little more than a tarball of that directory). But I don't see why including prv-xemacs.el in the ELPA package would be a problem. It's arguably wasteful, but I doubt anybody cares. This said, we could tweak the GNU ELPA build scripts so that some files are removed from the tarball. Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-05 15:14 ` Stefan Monnier @ 2012-12-05 16:46 ` David Kastrup 2012-12-05 17:22 ` [AUCTeX-devel] " Didier Verna 2012-12-05 18:36 ` Stefan Monnier 2012-12-06 1:46 ` Stephen J. Turnbull 1 sibling, 2 replies; 15+ messages in thread From: David Kastrup @ 2012-12-05 16:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: auctex-devel, emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> The XEmacs package building is sort of an aggravation. An XEmacs >> package contains all necessary files plus info source files in a rigid >> directory layout, possibly not unsimilar to what ELPA or any other >> package would do. > > Can you describe how does the XEmacs-package-building relates to the > VCS repository? Is it that the CVS layout was chosen specifically to > match the XEmacs package requirements? No. XEmacs was supported after the CVS layout had been established. An XEmacs package is assembled in a target directory hierarchy separate from the source tree. > Are those requirements incompatible with the ones for ELPA packages? No idea. -- David Kastrup ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [AUCTeX-devel] [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-05 16:46 ` David Kastrup @ 2012-12-05 17:22 ` Didier Verna 2012-12-05 18:36 ` Stefan Monnier 1 sibling, 0 replies; 15+ messages in thread From: Didier Verna @ 2012-12-05 17:22 UTC (permalink / raw) To: David Kastrup; +Cc: auctex-devel, Stefan Monnier, emacs-devel David Kastrup wrote: > Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> Can you describe how does the XEmacs-package-building relates to the >> VCS repository? Is it that the CVS layout was chosen specifically to >> match the XEmacs package requirements? > No. XEmacs was supported after the CVS layout had been established. An > XEmacs package is assembled in a target directory hierarchy separate > from the source tree. >> Are those requirements incompatible with the ones for ELPA packages? > > No idea. Not sure how this would work for a complex thing such as AUCTeX, but most of the time, it's not so difficult to support all those installation schemes from a single source tree. The key to packaging for XEmacs is that you need to provide a specific Makefile (sort of imposed by the infrastructure) with some predefined variables that you need to fill in. But the underlying organization of your source tree is pretty much what you want. Because the Makefile is specific, it's better to export your source tree to another directory (as David says) for XEmacs packaging. For my own packages, I have a generic infrastructure that does this. Every project contains a file named Makefile.pkg which is the XEmacs package one. I use 'hg convert' to export the tree to the appropriate place (XEmacs packages are under Mercurial) with a special .hgfilemap containing essentially this: rename Makefile.pkg Makefile but the rest of the source tree remains mostly the same. I like to organize my tree with lisp/*.el doc/*.texi etc/stuff etc., but you could also be plain flat of whatever. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-05 16:46 ` David Kastrup 2012-12-05 17:22 ` [AUCTeX-devel] " Didier Verna @ 2012-12-05 18:36 ` Stefan Monnier 1 sibling, 0 replies; 15+ messages in thread From: Stefan Monnier @ 2012-12-05 18:36 UTC (permalink / raw) To: David Kastrup; +Cc: auctex-devel, emacs-devel >> Can you describe how does the XEmacs-package-building relates to the >> VCS repository? Is it that the CVS layout was chosen specifically to >> match the XEmacs package requirements? > No. XEmacs was supported after the CVS layout had been established. An > XEmacs package is assembled in a target directory hierarchy separate > from the source tree. So it should be easy to adapt the script doing this assembly to work from the layout in the elpa/paclages/auctex directory. Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-05 15:14 ` Stefan Monnier 2012-12-05 16:46 ` David Kastrup @ 2012-12-06 1:46 ` Stephen J. Turnbull 1 sibling, 0 replies; 15+ messages in thread From: Stephen J. Turnbull @ 2012-12-06 1:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: auctex-devel, emacs-devel Stefan Monnier writes: > Can you describe how does the XEmacs-package-building relates to the > VCS repository? It doesn't restrict the repository in any way. The XEmacs package build system puts the packages into a specific layout (basically similar to an installed GNU Emacs of 19.x vintage, without the bin directory and with no libraries in the top level of the lisp/ directory, only subdirectories containing packaged libraries). The build system has sufficient flexibility to handle the AUCTeX source layout, and any future variation of it that I can imagine without hallucinogens. Updating it to handle future changes to AUCTeX's source layout is *purely* our problem. AUCTeX's build system does the same job in a different way. The two systems have different purposes. AUCTeX's is to avoid a requiring that its users and developers maintain a specific build environment just for XEmacs packages. Ours is to guarantee that our distributed packages are built in a controlled environment. As far as I can see, neither of these should affect GNU Emacs or GNU ELPA for quite a while. I think the Emacs maintainers should be vaguely aware of the build environment issue, because there's a possibility that as ELPA expands and becomes widely used, inconsistencies among packages distributed stand-alone may arise. However, since Emacs has a policy of eschewing support for non-GNU systems when that conflicts with the optimal support for GNU, I think ELPA will find it much easier to support AUCTeX's build system directly. It's difficult for us because it depends on utilities that are normally not present on Windows, for example. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-05 14:24 ` David Kastrup 2012-12-05 14:39 ` [AUCTeX-devel] " Uwe Brauer 2012-12-05 15:14 ` Stefan Monnier @ 2012-12-15 14:08 ` Tassilo Horn 2 siblings, 0 replies; 15+ messages in thread From: Tassilo Horn @ 2012-12-15 14:08 UTC (permalink / raw) To: David Kastrup; +Cc: auctex-devel, Stefan Monnier, emacs-devel David Kastrup <dak@gnu.org> writes: >>> The only remaining problem I can imagine is for those few files >>> which aren't FSF-copyright and hence aren't in the ELPA package, but >>> IIUC these are obsoletish and could just be dropped (noone >>> complained about them missing from the ELPA version). >> >> Yes, these 5 or 6 files are only addons for some special latex >> styles. They are not important for auctex, and they could be dropped >> or easily rewritten by someone else with CA by just looking at the >> corresponding latex style but not the current code. > > Also possible to go assignment-shopping for them once again. Did that now, and all four are going to assign copyright to the FSF. Bye, Tassilo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [AUCTeX-devel] [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. 2012-12-05 14:06 ` Tassilo Horn 2012-12-05 14:24 ` David Kastrup @ 2012-12-08 11:25 ` Ralf Angeli 1 sibling, 0 replies; 15+ messages in thread From: Ralf Angeli @ 2012-12-08 11:25 UTC (permalink / raw) To: Stefan Monnier; +Cc: auctex-devel, emacs-devel * Tassilo Horn (2012-12-05) writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >> Use elpa/packages/auctex as the official upstream. >> >>> We are planning to migrate to some DVCS anytime soon, but since >>> AUCTeX is expected to work with all Emacs versions >= 21.x plus >>> XEmacs >= 21.4.x, there's no way to develop it only as a part of >>> emacs in its bzr repo, although that would be very nice from a >>> maintenance point of view. Since we want to make standalone releases for older Emacsen and XEmacs, we'd also have to keep the build system. >> I don't see what prevents it. AFAICT it still contains all the >> backward compatibility code that's in CVS and nobody asked to remove >> it. If there are a couple more xemacs-specific files, I have no >> objection to you adding them. > > I'd welcome this but David and Ralf are more qualified to judge about > feasibility. Especially, there's much complexity in auctex's build > system in order to compile XEmacs packages, and that's a bit more than > just an auctex-compat.el. Another reason to keep the build system is the possibility to install preview.sty and its documentation in a TeX system tree. You can do this with `preview-install-styles' as well, but only for your user, unless you have sudo or root access. So I dunno if a site-wide install of AUCTeX and preview would be easily feasible with just the Emacs package system. >> The only remaining problem I can imagine is for those few files which >> aren't FSF-copyright and hence aren't in the ELPA package, but IIUC >> these are obsoletish and could just be dropped (noone complained about >> them missing from the ELPA version). > > Yes, these 5 or 6 files are only addons for some special latex styles. > They are not important for auctex, and they could be dropped or easily > rewritten by someone else with CA by just looking at the corresponding > latex style but not the current code. If we don't get the CAs I wouldn't mind either deleting those files. -- Ralf ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-12-15 14:08 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <E1TfF2V-0003Gn-No@vcs.savannah.gnu.org> 2012-12-03 20:40 ` [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release Stefan Monnier 2012-12-04 7:29 ` Tassilo Horn 2012-12-04 14:50 ` Stefan Monnier 2012-12-04 20:34 ` Tassilo Horn 2012-12-04 21:26 ` Stefan Monnier 2012-12-05 14:06 ` Tassilo Horn 2012-12-05 14:24 ` David Kastrup 2012-12-05 14:39 ` [AUCTeX-devel] " Uwe Brauer 2012-12-05 15:14 ` Stefan Monnier 2012-12-05 16:46 ` David Kastrup 2012-12-05 17:22 ` [AUCTeX-devel] " Didier Verna 2012-12-05 18:36 ` Stefan Monnier 2012-12-06 1:46 ` Stephen J. Turnbull 2012-12-15 14:08 ` Tassilo Horn 2012-12-08 11:25 ` [AUCTeX-devel] " Ralf Angeli
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).