Ralf Angeli <[EMAIL PROTECTED]> writes: > * David Kastrup (2005-05-19) writes: > >> Artemio Gonzalez Lopez <[EMAIL PROTECTED]> writes: >> >>> xemacs exiting. >>> Symbol's function definition is void: update-autoloads-from- >>> directorymake[1]: *** [install-metadata] Error 255 >>> make: *** [install] Error 2 > [...] >> * autoload.el (update-autoloads-from-directory): Removed. > [...] >> If anybody has a clue what we should use for replacing this, or wants >> to investigate, this would be appreciated. > > The doc string of `update-autoloads-from-directory' before it was > deleted contained the statement > > "You don't really want to be calling this function. Try using > `update-autoload-files' instead." > > And this function also accepts directories as argument: > > (defun update-autoload-files (files-or-dirs feature-prefix > &optional into-file force) > "Update all the autoload files associated with FILES-OR-DIRS. > FILES-OR-DIRS is a list of files and/or directories to be processed. > > An appropriate autoload file is chosen and a feature constructed for > each element of FILES-OR-DIRS. Fixup code testing for the autoload file's > feature and to provide the feature is added. > > If optional INTO-FILE is non-`nil', it should specify a file into which > the autoloads will be placed. Otherwise, the autoloads will be placed into > a file named `auto-autoloads.el' in the directory of each element in > FILES-OR-DIRS. > > FEATURE-PREFIX should be set to an appropriate prefix which will > be concatenated with \"-autoloads\" to produce the feature name. Otherwise > the appropriate autoload file for each file or directory (located in that > directory, or in the directory of the specified file) will be updated with > the directory's or file's autoloads and the protective forms will be added, > and the files will be saved. Use of the default here is unreliable, and > therefore deprecated. > > Note that if some of FILES-OR-DIRS are directories, recursion goes only > one level deep. > > If FORCE is non-nil, always save out the autoload files even if unchanged." > > So my suggestion would be something like this: > > --- prv-install.el 03 May 2005 14:40:13 +0200 1.10 > +++ prv-install.el 20 May 2005 11:32:09 +0200 > @@ -94,7 +94,11 @@ > ((string-equal "Generating autoloads for %s...done" fmt)) > (t (apply si:message fmt args)))) > (unwind-protect > - (update-autoloads-from-directory lisp-dir) > + (cond ((fboundp 'update-autoloads-from-directory) > + (update-autoloads-from-directory lisp-dir)) > + ((fboundp 'update-autoload-files) > + (update-autoload-files '(lisp-dir))) > + (t (error "Failed to generate autoloads.")))
I think we should go the whole nine yards here and just use the new function as long as it is available in XEmacs 21.4.not-too-small. We make clear enough that recent versions of XEmacs are required. > But I have to say that I am not really familiar with that code and > this could well be complete nonsense. Probably the `error' > statement is not needed because of `unwind-protect'. unwind-protect does _not_ catch errors (nor does condition-case catch all aborts). unwind-protect merely executes additional code while any abort, error, quit or throw bypasses normal control. But it does not stop the abort, error, quit or throw. Actually, I have not looked close enough to see whether the code is involved with that, but I could not let this opportunity for a little Lisp pontification pass by... > Additionally I had a hardware failure a few days ago and am > currently back on the old 200MHz machine with 100MB of diskspace > left. That means neither do I have an Emacs 21 nor an XEmacs 21.5 > for testing. For a moment I thought you were talking about 100MB of main memory and wanted to mention that I used Emacs-21 and preview-latex on a 133MHz system with 32MB of RAM (and that was before Jan-�ke came up with dvipng). But 100MB of disk space: that's tough. Nowadays. I remember the time when I paid about 2000DM for a 140MB SCSI drive. Of course, while the price per kilobyte has gone down considerably since then, the price per kilogram would still be a bargain nowadays. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ bug-auctex mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-auctex
