emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unload-feature questions and thoughts


From: David Kastrup
Subject: Re: unload-feature questions and thoughts
Date: Sun, 04 Feb 2007 19:32:33 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.93 (gnu/linux)

"Juanma Barranquero" <address@hidden> writes:

> 3.- A weirdness of load vs. autoload. Let's suppose we have a package
> test.el, with:
>
>  ;;;;; test.el ;;;;;
>  (defun test-fun () (interactive) t)
>  (provide 'test)
>  ;;;;;;;;;;;;;;;;;;;
>
> and we create an autoload for it:
>
>  (autoload 'test-fun "test" nil t)
>
> Now, if we do load test.el by using the autoload mechanism, i.e.,
>
>  M-x test-fun RET
>
> then the autoload is recorded:
>
>  (get 'test-fun 'autoload) => ("test" nil t nil)
>
> However, if we load test.el with `load' or `require', the autoload is
> not recorded:
>
>  (require 'test)
>  (get 'test-fun 'autoload) => nil
>
> Which is not very important, but affects the ability of
> `unload-feature' to do its work: it cannot restore an autoload if it
> is not recorded in the property list.

We had this discussion already.  IIRC, load could be used multiple
times and in so many contexts, that is was not reasonable to expect it
to be undoable.

As one consequence, AUCTeX typically uses a startup-file looking the
following:

;;; auctex.el
;;
;; This can be used for starting up AUCTeX.  The following somewhat
;; strange trick causes tex-site.el to be loaded in a way that can be
;; safely undone using (unload-feature 'tex-site).
;;
(autoload 'TeX-load-hack
  (expand-file-name "tex-site.el" (file-name-directory load-file-name)))
(TeX-load-hack)

and then we have

TeX-load-hack is an alias for `ignore' in `tex-site.el'.
(TeX-load-hack &rest IGNORE)

Do nothing and return nil.
This function accepts any number of arguments, but ignores them.

[back]

Before we coded this hack, there was a discussion on emacs-devel
because I had been surprised, too.

Anyway, this is most emphatically not something that should be changed
now.  But maybe it would be worth documenting something about it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]