From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: Tangling takes long - profiling and calling R Date: Tue, 16 Jun 2015 16:42:32 +0200 Message-ID: References: <87ioaobvl1.fsf@selenimh.access.network> <87a8vzc1u8.fsf@selenimh.access.network> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4s4Y-0007kk-QN for emacs-orgmode@gnu.org; Tue, 16 Jun 2015 10:42:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4s4V-0006o8-Dv for emacs-orgmode@gnu.org; Tue, 16 Jun 2015 10:42:42 -0400 Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:33211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4s4V-0006ne-8E for emacs-orgmode@gnu.org; Tue, 16 Jun 2015 10:42:39 -0400 Received: by wiwd19 with SMTP id d19so105643959wiw.0 for ; Tue, 16 Jun 2015 07:42:38 -0700 (PDT) In-Reply-To: <87a8vzc1u8.fsf@selenimh.access.network> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: "emacs-orgmode@gnu.org" Envoy=C3=A9 de mon iPhone > Le 16 juin 2015 =C3=A0 13:46, Nicolas Goaziou a =C3= =A9crit : >=20 > Rainer M Krug writes: >=20 >> I would not remove it as even I have some org files using them - shame >> on me. >=20 > We can check for that in Org Lint and warn the user. That would be a really good idea! >=20 >> But what about making it user configurable? a variable >> ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil wou= ld >> enable this additional code, if nil it would be skipped? The default >> should be set to ~t~ to be backward compatible. >=20 > This looks like backward-compatibility hell to me. If we make it > conditional the feature is no longer deprecated, is it? >=20 > The more general question is: how many years do we need to wait before > removing a deprecated (i.e., marked as such) feature? Before deleting it, one should get a warning that a certain feature is depre= cated. At the moment, it is only mentioned in the help (as far as I am aware= ). >=20 > Regards,