Hi Nicolas, 2015ko uztailak 2an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > Aaron Ecay <aarone...@gmail.com> 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/87fvg07vzi.fsf@Rainer.invalid>, 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/87r3zlrcnt....@gmail.com>. 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/87r3zlrcnt....@gmail.com>. 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
