From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ryan Newsgroups: gmane.emacs.bugs Subject: bug#3984: Date: Wed, 18 Sep 2013 17:47:58 -0700 Message-ID: <523A49BE.3060109@thompsonclan.org> References: <20E00C7675E64356BF2F0B2A7E0ABDB1@us.oracle.com> <5232D333.8030206@thompsonclan.org> <523359CD.2070904@thompsonclan.org> <5233670E.4030703@thompsonclan.org> <5237C9FF.1000809@thompsonclan.org> <52388FEB.6020007@thompsonclan.org> <523A37A4.5060505@thompsonclan.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1379551759 18305 80.91.229.3 (19 Sep 2013 00:49:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Sep 2013 00:49:19 +0000 (UTC) Cc: 3984@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 19 02:49:21 2013 Return-path: Envelope-to: geb-bug-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 1VMSQq-0007ah-JN for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Sep 2013 02:49:21 +0200 Original-Received: from localhost ([::1]:49220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMSQp-0001r2-QR for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Sep 2013 20:49:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMSQg-0001ql-3B for bug-gnu-emacs@gnu.org; Wed, 18 Sep 2013 20:49:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMSQY-0007aK-Ov for bug-gnu-emacs@gnu.org; Wed, 18 Sep 2013 20:49:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMSQY-0007aG-Lz for bug-gnu-emacs@gnu.org; Wed, 18 Sep 2013 20:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VMSQY-0005XO-4e for bug-gnu-emacs@gnu.org; Wed, 18 Sep 2013 20:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ryan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Sep 2013 00:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 3984 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 3984-submit@debbugs.gnu.org id=B3984.137955169221213 (code B ref 3984); Thu, 19 Sep 2013 00:49:01 +0000 Original-Received: (at 3984) by debbugs.gnu.org; 19 Sep 2013 00:48:12 +0000 Original-Received: from localhost ([127.0.0.1]:47734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VMSPj-0005W4-IR for submit@debbugs.gnu.org; Wed, 18 Sep 2013 20:48:11 -0400 Original-Received: from mail-pd0-f177.google.com ([209.85.192.177]:51804) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VMSPg-0005Vr-Os for 3984@debbugs.gnu.org; Wed, 18 Sep 2013 20:48:09 -0400 Original-Received: by mail-pd0-f177.google.com with SMTP id y10so7746419pdj.22 for <3984@debbugs.gnu.org>; Wed, 18 Sep 2013 17:48:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CSsqVM4Q9+fqmK8+gj1I1h8QrUrf6Ikdd67IBPLQ2Cc=; b=nE+HZOgDDNPkUo4kOjIfO73LkiC/pxPD7aFPqRDHCmgpQae4r6m6hnY1RsxEC1lWdc HUF48h+tdvEgOnsdQBnLB9WUm1OWCwTxeZ1q5m+WaigWyIpW1jrnutnkNUBuOE1/vHuO XYlfZYLscwBS2emoozjJIPEL8TYz8PHTya8VCrgQ5FZSuTt84dVJcP5CbKImjVze6Zr1 /ezOc1YSFIidNqKR2jN84be6fV2HiPQFJ3s4aU7WH89/TAFykxxG9vTT92VhJ4b56lii e4c7iTBBFt//goAuT3tVAzz4UG9CdhX7eoLnJPdOvPmK3Qw7FMOmiuzZcXo2brOYdOeS 6U/g== X-Gm-Message-State: ALoCoQkDfF7JBfHhXexuXoPF1KHHQv9PhZYMmZGLnWGDFE5HYJIE8R8j/8BKK/P04eW2CFRU9eiR X-Received: by 10.66.121.131 with SMTP id lk3mr45924684pab.61.1379551682646; Wed, 18 Sep 2013 17:48:02 -0700 (PDT) Original-Received: from wireless-121-195.scripps.edu (wireless-121-195.scripps.edu. [137.131.121.195]) by mx.google.com with ESMTPSA id dw3sm5427562pbc.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 17:48:01 -0700 (PDT) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 In-Reply-To: <523A37A4.5060505@thompsonclan.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:78544 Archived-At: After reading and finally comprehending the definition of "advice--called-interactively-skip", I think I have a possible solution that doesn't require a top-down search, but it would require some minor rearchitecting of nadvice. Basically, once we know that a particular stack frame is a call to the innermost unadvised form of an advised function, it is relatively easy to walk up the stack looking for the outermost advice. This is what "advice--called-interactively-skip" does. (Although reading through it I don't see where the bug is that prevents it recognizing the before advice in my example.) The problem, then, is knowing when a function is advised, given only the unadvised form and a position in the stack. If we always unconditionally wrap an unadvised function with a function that we can easily identify, then we can easily check whether it has been advised. To that end, I propose the following: ;; Generate a private symbol (defvar nadvice--indicator-symbol (make-symbol "nadvice--indicator-symbol")) (defun wrap-function-in-indicator-lambda (func) `(lambda (&rest args) ,nadvice--indicator-symbol (apply ,func args))) (defun indicator-lambda-p (func) (eq nadvice--indicator-symbol (nth 2 (wrap-function-in-indicator-lambda (indirect-function func))))) If all advised functions are wrapped by a call to the above function "wrap-function-in-indicator-lambda", then when they are called, the call to the "indicator lambda" would always be 2 frames up from the call to the original unadvised function. This allows us to easily recognize an advised function on the stack by testing the function 2 frames up with "indicator-lambda-p". Once we know the function is advised, we can then initiate the search for the outermost advice's stack position. In order to implement this, I think "advice-add" and "advice-remove" need to be modified to automatically wrap/unwrap the original function in/out of the indicator. What do you think of this? Obviously my "indicator-lambda" could be replaced by e.g. a no-op before/after advice or something similar, which would have the same effect of making it easy to recognize the innermost call of an advised function based on the contents of specific stack frame positions above it. What do you think of this? -Ryan