all messages for Emacs-related lists mirrored at yhetil.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: Updating the GNU ELPA package of AucTeX
Date: Tue, 03 Sep 2013 16:19:03 +0200	[thread overview]
Message-ID: <874na2q97s.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <jwvmwnurpjl.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Tue, 03 Sep 2013 09:48:14 -0400")

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> It is not clear to me why the act of importing a runnable version of
>>> AUCTeX into ELPA should be precluded from running a Makefile rule.
>>> It is not like ELPA can directly access git repositories and extract
>>> whatever it wants, so the import will always involve explicit steps.
>
> Yes, GNU ELPA can and does "git pull" every day as part of its
> automatic procedure.

If it expects a package to be in a finished state upon pulling, it means
that any standard GNU package (which requires ./configure && make &&
sudo make install to work) is not supported.

The AUCTeX build procedure supports creating an XEmacs package.  The
XEmacs package is built using a system agnostic configuration which
detects most things at runtime (at some cost).

Basically you are asking that we throw away all configurability of
AUCTeX and convert its repository into an installed tree with a
"neutral" configuration.

How will its Texinfo files get converted into documentation readable as
PDF or info?  How will its intro.texi get converted into README by
makeinfo?  After all, every GNU package should have a README, right?
Our current procedures create this README.

>> The new Git ELPA could have the savannah auctex repository as a
>> submodule, so there wouldn't be two individual auctex repositories
>> that need to me synchronized manually.
>
> That's the intention, indeed (tho not technically as a Git submodule,
> but morally equivalent).

"Morally equivalent"?  You make it sound like you consider the current
AUCTeX repository immoral.

At any rate, it would be easy enough to create Makefile targets that
would export a setup suitable for ELPA.  It's not really superbly
apropos

      The "source code" for a work means the preferred form of the work
    for making modifications to it.  "Object code" means any non-source
    form of a work.

    [...]

      The "Corresponding Source" for a work in object code form means
    all the source code needed to generate, install, and (for an
    executable work) run the object code and to modify the work,
    including scripts to control those activities.

but of course, once you throw away any other way of configuring the
package, what remains is by definition the "preferred form for making
modifications" since nothing else exists anymore.

> I'd be OK with splitting auctex into 2 packages, but does
> preview-latex work without auctex?

No.  It would be nice to factor out some of its quite sophisticated
functionality into something independent from AUCTeX, LaTeX and in fact
also TeX, but at the current point of time preview-latex is not
independently useful.

-- 
David Kastrup

  reply	other threads:[~2013-09-03 14:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-29 16:19 Updating the GNU ELPA package of AucTeX Stefan Monnier
2013-08-30  7:34 ` Tassilo Horn
2013-08-30 12:31   ` Stefan Monnier
2013-09-03  7:32     ` Tassilo Horn
2013-09-03  7:42       ` David Kastrup
2013-09-03  9:00         ` Tassilo Horn
2013-09-03 13:48           ` Stefan Monnier
2013-09-03 14:19             ` David Kastrup [this message]
2013-09-03 19:15               ` [AUCTeX-devel] " Stefan Monnier
2013-09-03 19:29                 ` David Kastrup
2013-09-05 17:31                   ` [AUCTeX-devel] " Stefan Monnier
2013-09-06 10:31                     ` Tassilo Horn
2013-09-14  3:37                       ` Stefan Monnier

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

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

  git send-email \
    --in-reply-to=874na2q97s.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.