From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Andreas_R=F6hler?= Newsgroups: gmane.emacs.devel Subject: Re: [emacs-w3m:11603] Re: interactive-p obsolete Date: Wed, 06 Jul 2011 13:22:30 +0200 Message-ID: <4E144576.3090703@online.de> References: <4E13FCE4.8080309@easy-emacs.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1309952055 25598 80.91.229.12 (6 Jul 2011 11:34:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 6 Jul 2011 11:34:15 +0000 (UTC) Cc: Tim Cross To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 06 13:34:10 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 1QeQMs-0004uu-1F for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2011 13:34:10 +0200 Original-Received: from localhost ([::1]:39678 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeQMr-0008Rx-5P for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2011 07:34:09 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:49678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeQBo-000672-16 for emacs-devel@gnu.org; Wed, 06 Jul 2011 07:22:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QeQBk-0003M0-Hb for emacs-devel@gnu.org; Wed, 06 Jul 2011 07:22:43 -0400 Original-Received: from moutng.kundenserver.de ([212.227.126.171]:58502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeQBj-0003Lg-Pq for emacs-devel@gnu.org; Wed, 06 Jul 2011 07:22:40 -0400 Original-Received: from [192.168.178.27] (brln-4d0c17ac.pool.mediaWays.net [77.12.23.172]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MYtjH-1R1EDe406V-00VGxV; Wed, 06 Jul 2011 13:22:38 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11 In-Reply-To: X-Provags-ID: V02:K0:fW6K7uG1CBSwfL+09DyhyecfUWHn8sViIxRpbty3jer i5nXi+Gdp31ZTGL2LWy4HAaK9pkMUsHsnVr62ZiixVAyzlBuf5 hVgx9u94IXyJFwi4iVWgUK4VfungPVYbOyu+LLd9gsm1yw9fPm LcoS7RpaaG1gypckra53xJEBSPwFZQGpa9honypbnocLAWRXZc zY5H8HMOcwysMiERzjo4YJQ189NfecFdYGT7A6oUPM= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 212.227.126.171 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:141647 Archived-At: 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, slows 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. Instead 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 Andreas > > > On Wed, Jul 6, 2011 at 4:12 PM, Andreas Röhler > wrote: >> Hi, >> >> making `interactive-p' obsolete, does this change pay? >> >> I'm in favour of keeping interactive-p, resp. undoing that change. >> >> Cheers, >> >> Andreas >> >> >> -------- Original-Nachricht -------- >> Betreff: [emacs-w3m:11603] Re: interactive-p obsolete >> Datum: Wed, 06 Jul 2011 12:58:03 +0900 >> Von: Katsumi Yamaoka >> Antwort an: jidanni@jidanni.org, emacs-w3m@namazu.org >> Organisation: Emacsen advocacy group >> An: jidanni@jidanni.org >> CC: emacs-w3m@namazu.org >> >> In [emacs-w3m : No.11600] jidanni@jidanni.org wrote: >>> >>> On (info "(emacs-w3m) Gnus") we are told to use >>> (if (interactive-p) >>> However >>> This function is obsolete since 23.2; >>> use `called-interactively-p' instead. >>> Please update the paragraph and tell us what you used. Thanks. >> >> We cannot use `called-interactively-p', otherwise emacs-w3m won't >> work with old Emacsen. Some Lisp packages, even in the Emacs trunk, >> still use `interactive-p' for the same reason. >> >> >> >> > >