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:47:58 +0200 Message-ID: <07F390A6-B112-4E02-8417-E9280B24AC94@gmail.com> 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]:44798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4s9o-0006Tk-Db for emacs-orgmode@gnu.org; Tue, 16 Jun 2015 10:48:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4s9i-0000vL-3P for emacs-orgmode@gnu.org; Tue, 16 Jun 2015 10:48:08 -0400 Received: from mail-wg0-x22e.google.com ([2a00:1450:400c:c00::22e]:33768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4s9h-0000vF-TG for emacs-orgmode@gnu.org; Tue, 16 Jun 2015 10:48:02 -0400 Received: by wgez8 with SMTP id z8so14111756wge.0 for ; Tue, 16 Jun 2015 07:48:01 -0700 (PDT) In-Reply-To: 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: Sebastien Vauban Cc: "emacs-orgmode@gnu.org" Envoy=C3=A9 de mon iPhone > Le 16 juin 2015 =C3=A0 14:45, Sebastien Vauban a= =C3=A9crit : >=20 > Nicolas Goaziou writes: >> Rainer M Krug writes: >>=20 >>> I would not remove it as even I have some org files using them - shame >>> on me. >=20 > To be clear, are we talking of constructs such as: >=20 > --8<---------------cut here---------------start------------->8--- > ** Subtree > :PROPERTIES: > :tangle: no > :END: > --8<---------------cut here---------------end--------------->8--- >=20 > ? >=20 >> We can check for that in Org Lint and warn the user. >>=20 >>> But what about making it user configurable? a variable >>> ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil wo= uld >>> 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 > I understand your point, and I'm enclined to agree with you (for > a long-term sanity and stability of the mode we all cherish) -- even if > I dunno yet if I still use such (Well, if this is the above structure, > then, yes, I use it a lot as well...). >=20 >> The more general question is: how many years do we need to wait before >> removing a deprecated (i.e., marked as such) feature? >=20 > Your suggestion with Org-lint, or even writing a function that would > convert from the old to the new syntax, makes a shorter period > acceptable IMO. I don't think that it is that easy, as the new syntax is not equivalent to t= he old syntax. One example; defining one tangle target for the mother tree, a= nd others for the child trees. This is by no means trivial (or even possible= ) with the new syntax, while it would be possible with the old syntax (if I r= emember correctly).=20 So for backward compatibility, the support should stay, but one had to enabl= e it explicitly.=20 Cheers,=20 Rainer >=20 > Best regards, > Seb >=20 > --=20 > Sebastien Vauban >=20 >=20