From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitri Paduchikh Newsgroups: gmane.emacs.devel Subject: Re: Brittleness of called-interactively-p Date: Mon, 13 Jul 2015 20:17:24 +0500 Message-ID: <874ml8t7cr.fsf@gmail.com> References: <871tgeufzt.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1436800674 22732 80.91.229.3 (13 Jul 2015 15:17:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Jul 2015 15:17:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 13 17:17:49 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZEfUG-000798-S8 for ged-emacs-devel@m.gmane.org; Mon, 13 Jul 2015 17:17:45 +0200 Original-Received: from localhost ([::1]:55312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEfUG-0000qQ-AE for ged-emacs-devel@m.gmane.org; Mon, 13 Jul 2015 11:17:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEfUA-0000ps-A4 for emacs-devel@gnu.org; Mon, 13 Jul 2015 11:17:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZEfU5-0002tT-Do for emacs-devel@gnu.org; Mon, 13 Jul 2015 11:17:38 -0400 Original-Received: from mail-la0-x22f.google.com ([2a00:1450:4010:c03::22f]:33827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEfU1-0002q1-3X; Mon, 13 Jul 2015 11:17:29 -0400 Original-Received: by lagx9 with SMTP id x9so302322896lag.1; Mon, 13 Jul 2015 08:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=Ew/BmhuR6KlRjXlxn8VeJT1nLA6AazG8U+QaeAeuvGI=; b=GWqMuJNqYFuFxN/tQHs8j6vskdbITtM1XoedG4dtcf9oQWJYwxQziJNHSe7PXfiRq1 TUEwNLEkRDyI8q8zfR0QWfMjvj3IPk6Tvkva2DenAVBKmn6PfQ+dHvVI2rwuBydCgESv sQKaFNAr0ZMZySXKUcV6nFMWocNSBvBAfWVkRMvujr3vGKfRt69BBZICg3QzJhmj+zWF K2TTdaYQA68EpRXoImGh3QsD92wG14ARMMCCFRAzn7h+/bDOHaf5hBTLEG++s/eGZEf6 MXKEGg8CeLlCpA3aImzieEaOTYvzp0TyikSLSlFJtG4AieuQqM3NqluaPaB5d363AT3x tH7A== X-Received: by 10.152.28.73 with SMTP id z9mr32700752lag.93.1436800645998; Mon, 13 Jul 2015 08:17:25 -0700 (PDT) Original-Received: from gmail.com ([46.48.49.226]) by smtp.gmail.com with ESMTPSA id h3sm4911147lbj.19.2015.07.13.08.17.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2015 08:17:25 -0700 (PDT) In-Reply-To: (Richard Stallman's message of "Sun, 12 Jul 2015 17:59:22 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:187853 Archived-At: Richard Stallman writes: RS> Here's another approach: give 'interactive' a way to specify a variable RS> to bind for this purpose. That way, the variable would be bound only in RS> functions that want it, and it would not interfere with the function's RS> calling interface. It is not clear for me whether this approach will help to solve the current problem of macros wrapping fragments of code in lambdas. [...] RS> To get the right results when advising or instrumenting code, we could RS> define (advised-interactive foo) as an alternative to use in wrappers. RS> (defun foo (y) RS> (interactive) RS> (was-interactive in-foo) RS> ...) RS> (lambda (x) (advised-interactive in-foo) (message "I am at foo") (foo x)) RS> When the lambda gets called, 'advised-interactive' will bind 'in-foo' RS> to say whether the call was interactive, and it will suppress the RS> 'was-interactive' form in 'foo' from binding 'in-foo' (because they RS> bind the same variable). If I understand right, an instrumenting code must be aware of the variable name used internally by a function. That is, when writing defadvice I should look inside foo in order to figure out that internally it's using in-foo, and then add (advised-interactive in-foo) in the defadvice code. After this I will be able to determine whether advised function was called interactively or not. Is it right? If so then it doesn't seem very good since coupling with the internal state isn't good.