Re: Tramp as ELPA package

[Achim Gratz <Stromeko@nexgo.de>]

Stefan Monnier writes:
>> Would it be possible to go the same line as org-mode has done?
>
> I want to get rid of this Org hack, so I'm really not looking forward to
> adding more such exceptions.

As discussed before: The package requirements are too limiting to allow
larger packages that need to have something built or generated (or even
multiple autoload files) and it's not just Org that falls into this
category.

The other unsolved problem is that anything that gets built in to Emacs
releases still can't be later cleanly updated as a package because none
of the "built-in packages" are actually packages in the ELPA sense.

Last but not least I'll mention again that even if the two points above
were solved, there still is not mechanism to cleanly separate packages
installed at the system level (either with the Emacs release or
separately by the admin) and user-level packages.  Specifically, if
packages are installed at the system level, the user can either use them
all or none of them, but can't really chose on a per-package basis
(without jumping through a number of burning hoops, that is).

> What you can do is create a Tramp package on elpa.git and push releases
> there (complete with the pre-built auxiliary files).

Well, that'd be more or less the same hack as you use for Org, except
you use Git instead of an archive file.

> This is what AUCTeX does, basically (where the files that would
> ideally be auto-generated during packaging are instead stored in the
> elpa.git repository after making them manually).

That is a mistake and should not be forced on anyone.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables