From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.devel Subject: Re: Obsolete functions and variables Date: Fri, 11 Apr 2008 02:21:26 +0200 Message-ID: <47FEAF06.7060304@gmail.com> References: <18429.40810.598948.654442@kahikatea.snap.net.nz> <18430.39543.722541.830806@kahikatea.snap.net.nz> <47FEA27D.1050501@gmail.com> <18430.42670.396106.323297@kahikatea.snap.net.nz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1207873326 8892 80.91.229.12 (11 Apr 2008 00:22:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2008 00:22:06 +0000 (UTC) Cc: Juanma Barranquero , rms@gnu.org, emacs-devel@gnu.org To: Nick Roberts Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 11 02:22:38 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Jk72G-00031T-1V for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2008 02:22:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jk71X-0001t0-9a for ged-emacs-devel@m.gmane.org; Thu, 10 Apr 2008 20:21:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jk71N-0001oU-HD for emacs-devel@gnu.org; Thu, 10 Apr 2008 20:21:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jk71M-0001mn-0H for emacs-devel@gnu.org; Thu, 10 Apr 2008 20:21:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jk71L-0001mU-KH for emacs-devel@gnu.org; Thu, 10 Apr 2008 20:21:35 -0400 Original-Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jk71G-0004Z8-L1; Thu, 10 Apr 2008 20:21:31 -0400 Original-Received: from c83-254-150-27.bredband.comhem.se ([83.254.150.27]:64443 helo=[127.0.0.1]) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Jk71D-0002GR-8E; Fri, 11 Apr 2008 02:21:27 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 In-Reply-To: <18430.42670.396106.323297@kahikatea.snap.net.nz> X-Antivirus: avast! (VPS 080410-1, 2008-04-10), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.150.27 X-Scan-Result: No virus found in message 1Jk71D-0002GR-8E. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Jk71D-0002GR-8E 62e5fa5753c9d1963696020ad5ced6d0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6? (barebone, rare!) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:94919 Archived-At: Nick Roberts wrote: > > >> I guess the dangers generally outweigh the advantages but there's not > > >> much point in marking them obsolete if they're never going to be > > >> removed. > > > > > > I agree. I just don't expect it to happen. > > > > > > I am not sure I agree. Are not a function sometimes marked as obsolete > > because there is a new better version that works in more cases? The old > > obsolete function may still work in many cases. > > Obsolete \Ob"so*lete\, a. [L. obsoletus, p. p. of obsolescere. > See {Obsolescent}.] > 1. No longer in use; gone into disuse; disused; neglected; > > Hmm, this is starting to sound like Monty Python's dead parrot sketch! I am glad we are creative. > > Maybe a more visible warning when obsolete things are found would be > > good? (Using for example lwarn.) > > How would this work? Not in some hand wavy way but with a real code > explanation. Do you mean it is difficult to do this? After looking at the code I might think it is. I thought that eval warned about obsolete functions but it does not. I do not think eval cares about "obsolete-ness". It is the bytecompiler that does it and the warnings given by the byte compiler are rather visible, but they does not explain very much. Maybe a comment at the end of the compilation log could tell people to remove the use of obsolete things?