Re: [Bug-AUCTeX] Re: [AUCTeX] auctex installation fails under Mac OS X 10.4 and xemacs

[David Kastrup]

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2005-05-19) writes:
>
>> Artemio Gonzalez Lopez <address@hidden> 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