Bug#1678: w3-el: no install-info; elisp files; mailcrypt

[Raul Miller <moth@magenta.com>]

Dirk Eddelbuettel:
   I don't want to take them away from anyone, not even from Emacs
   specialists.  I simply want to have the option of installing them
   or not.

Well, you could delete them.

$ (cd /usr/lib/emacs/site-lisp/w3; for x in *.elc; do rm `basename $x c`; done)

   If I want to read or modify them, I can always grab the source
   package --- as with any C code.  But .el is source code, and we
   usually hide that from users that want to run binaries from in a
   .deb package. All I propose is to do the same with elisp code. And
   that idea seems well represented among debian packages. Here's a
   quick poll that shows that vm, the example I cited, is not
   atypical:

	   editors/emacs			only .elc files

Not precisely -- these are available as a separate package.

	   mail/itimer			        only .elc files
	   mail/vm				only .elc files
	   tex/auctex			        mostly .elc plus three .el files,

In my opinion, this is a bug.  The .el files should be available in
package form.  They are, after all, executable code.  [Which is why
I'm still not sure I should compress them for w3 -- once compressed
they're no longer executable code.]

   whereas
	   net/w3				el and elc files

I suppose I could release a w3-elc which has only the .elc files.
Alternatively, I could make it an install-time configuration option to
run that line of code that deletes the .el files for which
corresponding .elc files exist...  Actually, I kind of like this idea
-- I could also support compression for those people who want them
handy but need to save space.

I suspect this will become a much bigger issue once we start having
alternative implementations of emacs available.  At that point I
suspect I'll have to include something like w3's makefile as well
[because of byte-code incompatabilities].

--
Raul