emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Tangling takes long - profiling and calling R


From: Aaron Ecay
Subject: Re: [O] Tangling takes long - profiling and calling R
Date: Thu, 02 Jul 2015 17:11:54 +0100
User-agent: Notmuch/0.19+52~g1722ea2 (http://notmuchmail.org) Emacs/25.0.50.2 (x86_64-unknown-linux-gnu)

Hi Nicolas,

2015ko uztailak 2an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay <address@hidden> writes:
> 
>> 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’s document position, or from the call’s.
>> 
>> Before deprecating the feature, the bugs should be fixed (if they are
>> really bugs), and the semantic differences explicated better.
> 
> I'm all ears to bug reports.

Could you take a look at
<http://mid.gmane.org/address@hidden>, specifically the
paragraph beginning “That looks like a bug”?

> 
> 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’t want to argue the semantics excessively, but “deprecated” 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’t really
achieve this, as evidenced by the periodic discussions of this point that
we have.  Additionally, last year Eric commented that the deprecation was
“premature” <http://article.gmane.org/gmane.emacs.orgmode/87739>.  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’t distinguish between these two approaches.

> 
> I suggest to remove the old "dynamic" setting and improve the new
> "lexical" one, if needed. 

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 <http://mid.gmane.org/address@hidden>.  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
<http://mid.gmane.org/address@hidden>.  Another, more
ambitious, solution would be to use the parser cache for
org-entry-{properties,get}.  There was a patch for this
<http://article.gmane.org/gmane.emacs.orgmode/89326>, which never landed
for a variety of reasons.

There are differences in the expressivity of the two systems – such as
the (AFAICS new) one pointed out by Rainer in this thread – which have
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.

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]