🚀 go-pugleaf

Getting GNU in the uk

   pd@pd@x.co.uk writes:
      But are there any plans for a mail server for those of us with no ftp
      or easy uucp access?

'Course there's a mail server - you mail the UKUUG archives a tape and some 
money, and they mail it back to you with the elisp archive on it :-)
I think Lee keeps the archives from tut up to date, but I wouldn't bet on it.
Email info-server@{doc.ic.ac.uk,uk.ac.ic.doc} for more details. 

By the way, [music] ``Where did you get that @, where did you get that style''

On a similar topic; is anybody keeping an archive of gnu.emacs.sources? 
The archive on tut is somewhat sorted, but it doesn't keep a copy of everything
on the list

 Finally: Given the vast amount of elisp software floating around, I think it
would be a good idea if there was some kind of standard header for elisp
packages to make them easier to install and deinstall.

 My suggestion is to introduce a new top-level form, def-package. This form
would describe the files in the package, it's top level functions, what it
replaces, who wrote it, where the documentation is, etc, etc. For example, 
a hypothetical header for gnus might read as follows

(def-package gnus
  (version 3.13)
  (date ...)
  (supercedes 'gnus 'any)
  (class  'subsystems)
  (subclass 'mail-and-newsreaders)
  (author "Masanobu Umeda")
  (mailing-list "info-gnus-english@tut.cis.ohio-state.edu")
  (archive-site "prep.ai.mit.edu" "pub/gnu/gnus.tar.Z")
  (elisp-files '("gnus.el" "gnusmail.el" "gnusmisc.el" "gnuspost.el"
		 "mhspool.el" "nnspool.el" "nntp.el" "tcp.el"))
  (texinfo-files '("gnus.texinfo"))
  (info-files '("gnus"))
  (other-files '("README" "INSTALL"))
  (top-level '(
	       (gnus "gnus" "The GNUS news reader" t)
	       ))
  (bug-method 'mail-to-mailing-list)
  (configuration-method '(lambda (package version system-widep)
			   (load (get-file package version "gnusmisc"))
			   (gnus-configure package version system-widep)))

This information could then be read by an installation function, which could
then install the files in an appropriate sub-directory, build the info file
then compress and install it in the appropriate info directory. It could 
prompt for any configuration details, and set up the appropriate autoloads
and variables, on either a per user or system wide basis.
  
Whadya think? Worth implementing? If so what should the standard classes
be? How should it deal with updates to existing files, and with all those
little dired enchancements?

Simon

ses@techunix.technion.ac.il | `Smoke me a kipper, I'll be back for breakfast'
ses@techunix.bitnet	    | Saddam Hussein now. Look and Feel, when?
------------------------------------------------------------------------------
Tel +972-4-292658, Fax +972-4-236212, Tlx 46406  |A Corner of a Foreign field.