unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ryan <rct@thompsonclan.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 3984@debbugs.gnu.org
Subject: bug#3984:
Date: Wed, 18 Sep 2013 17:47:58 -0700	[thread overview]
Message-ID: <523A49BE.3060109@thompsonclan.org> (raw)
In-Reply-To: <523A37A4.5060505@thompsonclan.org>

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





  reply	other threads:[~2013-09-19  0:47 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-30 22:37 bug#3984: 23.0.96; defadvice of call-interactively defeats interactive-p Drew Adams
2009-07-31  1:58 ` Stefan Monnier
2009-07-31 14:19   ` Drew Adams
2009-07-31 19:31     ` Stefan Monnier
2009-07-31 20:04       ` Drew Adams
2011-10-10  6:00 ` Kai Tetzlaff
2011-10-11 14:26   ` Drew Adams
2011-10-11 15:46     ` Stefan Monnier
2011-10-11 16:05       ` Drew Adams
2013-09-10 20:29 ` Christopher Wellons
2013-09-11  0:29   ` Stefan Monnier
2013-09-13  8:56 ` bug#3984: Fix for #3984 Ryan
2013-09-13 13:18   ` Stefan Monnier
2013-09-13 18:30     ` Ryan
2013-09-13 19:27       ` Ryan
2013-09-13 21:02         ` Stefan Monnier
2013-09-17  3:18           ` Ryan
2013-09-17 13:10             ` Stefan Monnier
2013-09-17 17:22               ` bug#3984: Ryan
2013-09-18  1:46                 ` bug#3984: Stefan Monnier
2013-09-18 23:30                   ` bug#3984: Ryan
2013-09-19  0:47                     ` Ryan [this message]
2013-09-19  3:38                       ` bug#3984: Stefan Monnier
2013-09-19  8:06                         ` bug#3984: Ryan
2013-09-19 19:23                           ` bug#3984: Ryan
2013-09-19 20:59                             ` bug#3984: Stefan Monnier
2013-09-19 21:59                             ` bug#3984: Ryan
2013-09-20  4:23                               ` bug#3984: Ryan
2013-09-20  4:58                                 ` bug#3984: Fix case where call-interactively is advised Ryan
2013-09-20  5:03                                   ` bug#3984: Ryan
2013-09-20 14:35                                 ` bug#3984: Stefan Monnier
2013-09-20 16:54                                   ` bug#3984: Ryan
2013-09-20 16:56                                     ` bug#3984: Ryan
2013-09-20 14:54                               ` bug#3984: Stefan Monnier
2013-09-20 16:50                                 ` bug#3984: Ryan
2013-09-20 19:59                                   ` bug#3984: Stefan Monnier
2013-09-13 10:24 ` bug#3984: bug#123: Potential fix Ryan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=523A49BE.3060109@thompsonclan.org \
    --to=rct@thompsonclan.org \
    --cc=3984@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).