[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mailcrypt - EMACS package maintainers please read this message.

>>>>> "RB" == Rob Browning.

>> I think it may be useful for package who don't have to do flavor
>> dependent sort of things: it make sense to me to have this call when
>> you install or remove the add-on package itself.  But I don't
>> understand its purpose, when you install or remove a specific version
>> of emacs, considered it will be called with that flavor as argument
>> and the fact every add-on Depends on at least some emacsen.

RB> It's so that if a script has no flavor dependent stuff, it can just
RB> react to an "emacs" first argument and ignore any others.  Any
RB> scripts that do byte-compiling will probably do the opposite (that
RB> is, only react to a non "emacs" fist argument).  I know it's a
RB> little redundant, but it doesn't hurt anything, and it allows the
RB> add-on package maintainers more control over how they structure
RB> their scripts.

Yes, I did understand what you say, but it makes sense to me only when you
are installing an add-on package, not when you are installing an emacs

If you're going to install XEmacs20, tm is supposed to have to byte
compile just for XEmacs20; it should already have been called at its
(tm's) installation time to byte compile for other emacsen (or when the
other emacsen where installed) and it should have already done flavor
independent things it may have needed (I mean, the first time it was
called, at its installation time).  Am I wrong?

RB> Well, the ${elc_dir} here is the add on package's directory, so
RB> there anyone who put anything else in there is asking for trouble.

Sorry, I noticed there was an attempt to remove not owned elc files later
in the script and overlooked the value of ${elc_dir}. :-)

RB> Again, since each add-on package has it's own subdirectory
RB> "playground", I don't see that this is necessary.

Yes, I agree.

RB> OK, I hadn't thought of that, but I'd say that you should document
RB> that you need to call update-tex-elisp script after changes to
RB> /usr/local, and then the cron task can stay around as a catch-all.

It will be done in the next release.  BTW: I don't like the current script
name (auctex-auto-load), I'd rather have update-tex-elisp, but I hesitate
to change it, in the event someone already relies on it.

RB> [ other good stuff about site-start.d elided ]

RB> I think most of this will have to be left as a package by package
RB> decision.  But in general, I agree that there either needs to be a
RB> way to "turn the package off" for those users on a given system that
RB> don't want it always loded for them, or just not have it loaded
RB> automatically at startup.

I told you that since you're really going to extensively update emacs
packages policies: I think we could add suggestions [1] of this type too,
but maybe it's better to have another, smaller, proposal about these minor

[1]: Just to give each developer a set of different package startup
options to choose from.

RB> At the very least, the site-start.d mechanism should be used to make
RB> sure that load-path contains the package's relevant directories, and
RB> that autoloads are set up properly.  I think tm already does require
RB> you to do something to "turn it on".

This is exactly how I'd like the site-start.d mechanism to be used.

>> I plan to release AUC TeX and Mailcrypt using /usr/share as soon as
>> the new emacsen come out: is there an estimate time?

RB> Well, I'm ready to go, but we really have to wait for a new emacs 19
RB> package that knows about emacsen-common.  I could go ahead and
RB> upload emacs20 to experimental, and you could start playing with
RB> that, but it'll require that you purge emacs 19 and all the packages
RB> that depend on it.  Let me know if you're interested.

No thanks, I don't have very much free time now, better wait for the new
emacs19, before I start playing with it (I have no spare machines handy
and I have to use Emacs every day).


Davide G. M. Salvetti - IW5DZC [JN53fr]
Take a look at Debian GNU/Linux: <http://www.debian.org/>.
Debian is the free operating system with open development model.

Reply to: