|Subject:||bug#3984: bug#123: Potential fix|
|Date:||Fri, 13 Sep 2013 03:24:19 -0700|
|User-agent:||Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8|
Dear all,I "fixed" this in my ido-ubiquitous package by completely reimplementing "called-interactively-p" and "interactive-p" in pure elisp: https://github.com/DarwinAwardWinner/ido-ubiquitous/commit/f0c42e289a614071e22ad2c08297a7ebd60ba1cc
Apart from simply translating the C code in elisp, I made two key adjustments to the logic: first, I filter out all evidence of advice from the call stack before checking if the caller is "call-interactively". Second, I relax the definition of "caller is call-interactively" to include any symbol with the same "symbol-function" as call-interactively, or any function that is the same as the symbol-function of call-interactively. Combined, these adjustments mean that defining advice on call-interactively no longer results in erroneous return values from these two interactivity-testing functions.
I have implemented this in elisp because that is the only way to redefine functions in a running emacs session, but there's no reason that the C code couldn't be adapted to use the same logic.
|[Prev in Thread]||Current Thread||[Next in Thread]|