From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: [emacs-w3m:11603] Re: interactive-p obsolete Date: Thu, 7 Jul 2011 10:06:05 +1000 Message-ID: References: <4E13FCE4.8080309@easy-emacs.de> <4E144576.3090703@online.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1309997190 22434 80.91.229.12 (7 Jul 2011 00:06:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2011 00:06:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?ISO-8859-1?Q?Andreas_R=F6hler?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 07 02:06:26 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qec6r-0002ve-HH for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2011 02:06:25 +0200 Original-Received: from localhost ([::1]:38948 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qec6q-00068F-GI for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2011 20:06:24 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qec6a-00067f-KW for emacs-devel@gnu.org; Wed, 06 Jul 2011 20:06:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qec6Y-00070s-Lr for emacs-devel@gnu.org; Wed, 06 Jul 2011 20:06:08 -0400 Original-Received: from mail-vw0-f41.google.com ([209.85.212.41]:52232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qec6Y-00070m-8c for emacs-devel@gnu.org; Wed, 06 Jul 2011 20:06:06 -0400 Original-Received: by vws4 with SMTP id 4so449403vws.0 for ; Wed, 06 Jul 2011 17:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GL0hrX/R+q+JIUSvHDR6H0NeqYIts7jVKx3vY+Tn8tI=; b=k/c8M/Z940tCd2tppCb5g1h6fZtC/2C7sHZWmTyrPNsuFoxOcuXVIo1ezrsVpqsxuN cDma2rlOU4mQ3ebXBlNJoDvj3yXs5ZHECqU6AesMF0jcCGpQnfLv8STDX8Sd8DphKG8O O7RpmD4lc71FXJyVea4zw1uQDQ5KrKMIjuiFI= Original-Received: by 10.220.6.3 with SMTP id 3mr60552vcx.216.1309997165316; Wed, 06 Jul 2011 17:06:05 -0700 (PDT) Original-Received: by 10.220.84.202 with HTTP; Wed, 6 Jul 2011 17:06:05 -0700 (PDT) In-Reply-To: <4E144576.3090703@online.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.212.41 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:141704 Archived-At: On Wed, Jul 6, 2011 at 9:22 PM, Andreas R=F6hler wrote: > Am 06.07.2011 09:09, schrieb Tim Cross: >> >> I don't believe the argument of not being able to use the new function >> because of the need for backwards compatibility is valid. You can >> solve this problem in a number of ways and maintain backwards >> compatibility. In fact, its not uncommon to have to do this or that >> different from wanting to maintain compatibility with emacs and xemcas >> etc. If there is some other argument for not making the change, I'd be >> interested in hearing it. >> >> Tim > > Hi Tim, > > from my perspective --which might miss the point anyway-- exist several > reasons for reverting the change. > > First: what is the gain? IMHO new function is more difficult to use, slow= s > down writing, needs more reflection than the old one. > > So to say: some classic over-specification. > We must not differentiate here, better a simple one-for-all-function not > bothering for specific argument: just interactive-p > > Alltogether new design evens doesn't deliver the basics needed, saying: > > "This function is meant for implementing advice and other > function-modifying features. =A0Instead of using this, it is sometimes > cleaner to give your function an extra optional argument whose > `interactive' spec specifies non-nil unconditionally ("p" is a good > way to do this), or via (not (or executing-kbd-macro noninteractive))." > > : hodge-podge > Hi Andreas My main point was that backwards compatibility, as suggested in your original post, was not sufficient justification to revert things as it is trivial to add code that would provide this compatibility. Furthermore, in many cases, packages already have this compatibility layer in order to support both GNU Emacs and XEmacs (see the org-mode example which has since been posted). However, while I may have things a bit mixed up, as I understand it, there are some good reasons for the change. It isn't just a change made for the sake of it. Some may debate whether the reasons are sufficient, but for me they seem reasonable. Others with more experience and better memories are probably able to fill in things better, but from memory, there are some problems with the use of interactive-p because people misinterpret what it means and because they tend to use it without thinking about what 'interactive' means. Its one of those subtle issues that you may think you understand and everyone else understands in the same way until you begin to talk to others. You then find out there are a number of situations where it isn't as clear as it originally seemed and that you do need to think about the context where you use such a test and what it is you really are wanting to test for. I also believe the water was made even more 'muddy' by the fact that a form of called-interactive-p, without an argument, already existed. People found it hard to know when to use called-interactive-p or interactive-p or what the difference was or why there was both. To clarify matters, one had to go. There was a discussion a couple of years back regarding this. At the time, it was recognised that fixing it would improve elisp in the long-term, but doing so was going to cause some pain. I believe that the result, called-interactive-p with an optional argument and the marking of interactive-p as obsolete was considered the solution with the least pain and best outcome and seems like a reasonable compromise to me. Once interactive-p is actually removed, we will realise the benefits of having a single predicate to test for 'interactive' and because of the additional argument, possibly a predicate that is applied after more thought as to what the programmer is really testing for, hopefully resulting in code where intentions are clearer and therefore, easier to maintain. Tim