From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Tangling takes long - profiling and calling R Date: Thu, 02 Jul 2015 17:11:54 +0100 Message-ID: <878uaybktx.fsf@gmail.com> References: <87ioaobvl1.fsf@selenimh.access.network> <87a8vzc1u8.fsf@selenimh.access.network> <07F390A6-B112-4E02-8417-E9280B24AC94@gmail.com> <87zj3gj7qg.fsf@gmail.com> <87h9pmn5fh.fsf@nicolasgoaziou.fr> Mime-Version: 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]:60163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAh5w-0007ka-G4 for emacs-orgmode@gnu.org; Thu, 02 Jul 2015 12:12:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAh5t-0006sh-3j for emacs-orgmode@gnu.org; Thu, 02 Jul 2015 12:12:12 -0400 Received: from mail-wg0-x232.google.com ([2a00:1450:400c:c00::232]:35478) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAh5s-0006rm-QJ for emacs-orgmode@gnu.org; Thu, 02 Jul 2015 12:12:09 -0400 Received: by wgjx7 with SMTP id x7so67290268wgj.2 for ; Thu, 02 Jul 2015 09:12:07 -0700 (PDT) In-Reply-To: <87h9pmn5fh.fsf@nicolasgoaziou.fr> 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 , Rainer M Krug Cc: Sebastien Vauban , "emacs-orgmode@gnu.org" Hi Nicolas, 2015ko uztailak 2an, Nicolas Goaziou-ek idatzi zuen: >=20 > Hello, >=20 > Aaron Ecay writes: >=20 >> There is also a semantic difference in the two approaches as to whether >> a remote invocation of a babel block (via e.g. #+call) uses the >> properties from the block=E2=80=99s document position, or from the call= =E2=80=99s. >>=20 >> Before deprecating the feature, the bugs should be fixed (if they are >> really bugs), and the semantic differences explicated better. >=20 > I'm all ears to bug reports. Could you take a look at , specifically the paragraph beginning =E2=80=9CThat looks like a bug=E2=80=9D? >=20 > However, the point is not about deprecating the feature. It /is/ marked > as deprecated already, and has been so during the last two years. I don=E2=80=99t want to argue the semantics excessively, but =E2=80=9Cdepre= cated=E2=80=9D should mean that users: 1) actually change their behavior when creating new documents, or at least 2) are aware that the old behavior is in danger of disappearing. A footnote in the manual and a comment in the elisp file don=E2=80=99t real= ly achieve this, as evidenced by the periodic discussions of this point that we have. Additionally, last year Eric commented that the deprecation was =E2=80=9Cpremature=E2=80=9D . This arguably means (among other things) that more effort to publicize it and work on its replacement is needed, something that has not really happened. (Unless you count repetitive and inconclusive ML threads as a publicity campaign.) The inclusion of the warning in org-lint is a concrete step forward. > Keeping both is just confusing and not necessary, since you can override > properties locally, with appropriate arguments. Neither syntax is necessary, by this metric. We could just make do with local arguments, not needing properties at all. IOW, this doesn=E2=80=99t distinguish between these two approaches. >=20 > I suggest to remove the old "dynamic" setting and improve the new > "lexical" one, if needed.=20 The dynamic vs. lexical metaphor is not very helpful either. I myself invoked it, with opposite polarity, in the last thread. Achim and I had a long discussion, without reaching any conclusion. That discussion starts here . It might be good if you read that whole thread (which is the same one that I have already linked several times). There has been no justification for the new property system proposed other than questions of taste such as the above, and efficiency. The efficiency considerations could be solved in several ways. One obvious one would be to use a single call to org-entry-properties rather than N calls to org-entry-get. I feel like a broken record saying this, but it was a solution I suggested already, in the last thread . Another, more ambitious, solution would be to use the parser cache for org-entry-{properties,get}. There was a patch for this , which never landed for a variety of reasons. There are differences in the expressivity of the two systems =E2=80=93 such= as the (AFAICS new) one pointed out by Rainer in this thread =E2=80=93 which h= ave not been explained or justified. I hope that these can be addressed, and alternatives considered if necessary, before the change is imposed on org users. --=20 Aaron Ecay