From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.help Subject: Re: Is this a bug? Date: Tue, 03 Dec 2013 09:46:19 +0100 Message-ID: <87y5428gpw.fsf@tsdh.uni-koblenz.de> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1386060413 22577 80.91.229.3 (3 Dec 2013 08:46:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2013 08:46:53 +0000 (UTC) Cc: "help-gnu-emacs@gnu.org Help" To: Perry Smith Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Dec 03 09:46:58 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VnldB-0004fG-Fc for geh-help-gnu-emacs@m.gmane.org; Tue, 03 Dec 2013 09:46:57 +0100 Original-Received: from localhost ([::1]:40933 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnldA-0008Ss-TG for geh-help-gnu-emacs@m.gmane.org; Tue, 03 Dec 2013 03:46:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vnlci-0008Rt-IC for help-gnu-emacs@gnu.org; Tue, 03 Dec 2013 03:46:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vnlcb-0005zJ-8G for help-gnu-emacs@gnu.org; Tue, 03 Dec 2013 03:46:28 -0500 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:36563) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vnlcb-0005zD-1s for help-gnu-emacs@gnu.org; Tue, 03 Dec 2013 03:46:21 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 139E71A83CA; Tue, 3 Dec 2013 09:46:20 +0100 (CET) X-Virus-Scanned: amavisd-new at uni-koblenz.de Original-Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEmbLKYgO8nL; Tue, 3 Dec 2013 09:46:19 +0100 (CET) X-CHKRCPT: Envelopesender noch tsdh@gnu.org Original-Received: from tsdh.uni-koblenz.de (tsdh.uni-koblenz.de [141.26.67.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 912D91A83D3; Tue, 3 Dec 2013 09:46:19 +0100 (CET) In-Reply-To: (Perry Smith's message of "Mon, 2 Dec 2013 07:51:30 -0600") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 141.26.64.15 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:94801 Archived-At: Perry Smith writes: Hi Perry, > Now the non-working case. Repeat the above after adding advice: > > (defadvice load (before load-log activate) > (message "Loading %s" (ad-get-arg 0))) > > and I get an error with the stack: > > Debugger entered--Lisp error: (wrong-type-argument subrp (lambda (file > &optional noerror nomessage n$ > subr-name((lambda (file &optional noerror nomessage nosuffix must-suffix) It seems like a bug in 24.3 since your example now works with the current bzr trunk. Nevertheless, the docs explicitly warn about advising subrs like `load': ,----[ (info "(elisp)Advising Functions") ] | Unless you know what you are doing, do _not_ advise a primitive | (*note What Is a Function::). Some primitives are used by the advice | mechanism; advising them could cause an infinite recursion. Also, many | primitives are called directly from C code. Calls to the primitive from | Lisp code will take note of the advice, but calls from C code will | ignore the advice. `---- The concrete problem is that `help-C-file-name' assumes that a function defined in C is a subr. But when you add a piece of advice, the subr is wrapped in a lisp function, and then `subr-name' fails. --8<---------------cut here---------------start------------->8--- ELISP> (symbol-function 'load) # ELISP> (defadvice load (before load-log activate) (message "Loading %s" (ad-get-arg 0))) load ELISP> (symbol-function 'load) #[128 "\300\301\302.#\207" [apply ad-Advice-load # nil] 5 #("Advised function" 0 16 (dynamic-docstring-function advice--make-docstring))] --8<---------------cut here---------------end--------------->8--- After defining the advice with the current bzr version, the help buffer states "load is a compiled Lisp function" without any file link. That's better than an error, but still not perfect. One could get the original subr with (ad-get-orig-definition 'load) to also include a link to the C source. I just checked: with emacs 23, when you advised load or any other subr, C-h f still had a link to the C source, so IMHO that counts as a regression. Bye, Tassilo