unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: auctex-devel@gnu.org, emacs-devel@gnu.org
Subject: Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.
Date: Wed, 05 Dec 2012 15:24:50 +0100	[thread overview]
Message-ID: <87ip8gd1al.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87hao0mw44.fsf@thinkpad.tsdh.de> (Tassilo Horn's message of "Wed, 05 Dec 2012 15:06:35 +0100")

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

  reply	other threads:[~2012-12-05 14:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ip8gd1al.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=auctex-devel@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).