Re: problem with emacs configuration scripts

[tb@MIT.EDU (Thomas Bushnell, BSG)]

Rafael Laboissiere <rafael@icp.inpg.fr> writes:

> I understand that this discussion belongs to debian-policy and that it would
> be great to find a global solution.  However, could you please also send
> your future posts to debian-emacsen?  We may find a local solution for the
> emacsen init files, regardless of the final decision on debian-policy.

So the octave maintainer suggested doing something more like what we
do for init.d scripts.  Those scripts test for the existence of
relevant files, and exit cleanly if the files don't exist.  It would
be simple to say the same kind of thing for the emacs start files.  I
refer especially to the end of section 3.3.2 of the policy manual.

Currently the best way to do that is:

(if (some-condition-p)
    (progn 
	REST OF THE FILE
    ))

That's ugly, because it means that a script has to be fully embedded
in such a way.

Better would be to do

(if (not (some-condition-p))
    (throw 'some-tag nil))

This requires a suitable catch tag to be set up.  I have already sent
a suggestion to bug-gnu-emacs that load should set up such a tag
(which is done on many other lisp systems).  But that would take a
while to propogate.  So I think the master-loader widget for Debian
emacs should set up such a tag.

I think this solution would be elegant and optimal.

To summarize:

1) Require that emacs init scripts which happen to be conffiles behave
   nicely upon package removal, as already required for init.d scripts
   by 3.3.2 of the policy manual.  

2) Have the Debian emacs loader frob establish a catch around its
   invocations of load, to make (1) easier or other package
   maintainers.

We could do (2) immediately, and (1) as packages catch up.  They would
need to have a dependency on whichever version of the emacs package
first includes the relevant catch tag.

Given that the only two cases I know of this category of problem are
the init.d one and the emacs one, I'm happy to drop the more
far-sweeping policy proposal in favor of this.

If the emacs people are all happy with it, I could write up a suitable
paragraph for a formal policy amendment.  Perhaps that's not necessary
and it just needs to get added to to debian-emacs-policy.  It would go
in section 6C of that file.  Again, I'm happy to write exact language
if that would be useful.

Thomas