From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Juanma Barranquero" Newsgroups: gmane.emacs.devel Subject: unload-feature questions and thoughts Date: Sun, 4 Feb 2007 19:03:35 +0100 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1170612236 27291 80.91.229.12 (4 Feb 2007 18:03:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Feb 2007 18:03:56 +0000 (UTC) To: "Emacs Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 04 19:03:47 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HDliN-0007qk-HF for ged-emacs-devel@m.gmane.org; Sun, 04 Feb 2007 19:03:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HDliO-0005wW-T8 for ged-emacs-devel@m.gmane.org; Sun, 04 Feb 2007 13:03:48 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HDliE-0005wR-0j for emacs-devel@gnu.org; Sun, 04 Feb 2007 13:03:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HDliD-0005wF-In for emacs-devel@gnu.org; Sun, 04 Feb 2007 13:03:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HDliD-0005wC-Bu for emacs-devel@gnu.org; Sun, 04 Feb 2007 13:03:37 -0500 Original-Received: from nz-out-0506.google.com ([64.233.162.225]) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HDliC-0006NJ-Mi for emacs-devel@gnu.org; Sun, 04 Feb 2007 13:03:36 -0500 Original-Received: by nz-out-0506.google.com with SMTP id s1so1249218nze for ; Sun, 04 Feb 2007 10:03:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=N2ySLaOB5PJ4JZ98mg2RjCnBEXVyKxtj5mZe66choVRDyUyWUTFU4UYCkA+tssq0CuY73yx+27N1yIFW/z3kj5S2gPnCmC8erQSaXm2XKVEhdNDFJzOKLMcJ7y7fcfjP68/1pcjvqvnBLkbdQp2yxlfH2TzLv9HdDaTTcCHNXM4= Original-Received: by 10.114.175.16 with SMTP id x16mr526030wae.1170612215502; Sun, 04 Feb 2007 10:03:35 -0800 (PST) Original-Received: by 10.114.234.16 with HTTP; Sun, 4 Feb 2007 10:03:35 -0800 (PST) Content-Disposition: inline X-detected-kernel: Linux 2.4-2.6 (Google crawlbot) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:65853 Archived-At: 1.- Currently, `unload-feature' (from loadhist.el) does not expect entries on `load-history' of the form (autoload . SYMBOL) or (defface . SYMBOL). Unloading a package which defines either one produces messages like Unexpected element (defface . myface) in load-history which should be reserved, I think, to really unexpected items in the load-history, not perfectly usual ones like those above. AFAICS, there's no way to delete an existing face, so ignoring the item is the best option (or, alternatively, giving a more significant warning, like "Face MYFACE can not be unloaded"). Autoload entries, OTOH, can be unloaded like a function; so I propose to commit the attached patch. 2.- `unload-feature' returns `load-history', but this is not documented, and a PITA when you're using `unload-feature' in a context that evaluates its result, like IELM. Should we document what it does now, or (preferred) just force it to return nil? 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. /L/e/k/t/u Index: lisp/ChangeLog =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/ChangeLog,v retrieving revision 1.10649 diff -u -2 -r1.10649 ChangeLog --- lisp/ChangeLog 4 Feb 2007 17:29:50 -0000 1.10649 +++ lisp/ChangeLog 4 Feb 2007 17:50:33 -0000 @@ -1,2 +1,8 @@ +2007-02-04 Juanma Barranquero + + * loadhist.el (unload-feature): Process also `load-history' + entries of the form `(autoload . SYMBOL)' (by treating them like + `defun'), and `(defface . SYMBOL)' (by ignoring them). + 2007-02-04 David Kastrup Index: lisp/loadhist.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/loadhist.el,v retrieving revision 1.43 diff -u -2 -r1.43 loadhist.el --- lisp/loadhist.el 21 Jan 2007 03:53:11 -0000 1.43 +++ lisp/loadhist.el 4 Feb 2007 16:59:22 -0000 @@ -216,5 +216,5 @@ (provide (setq features (delq (cdr x) features))) - (defun + ((defun autoload) (let ((fun (cdr x))) (when (fboundp fun) @@ -225,5 +225,5 @@ (fset fun (cons 'autoload aload)) (fmakunbound fun)))))) - ((t require) nil) + ((t require defface) nil) (t (message "Unexpected element %s in load-history" x))) ;; Kill local values as much as possible.