From: Aaron Ecay <aaronecay@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>,
Rainer M Krug <r.m.krug@gmail.com>
Cc: Sebastien Vauban <sva-news@mygooglest.com>,
"emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: Tangling takes long - profiling and calling R
Date: Thu, 02 Jul 2015 17:11:54 +0100 [thread overview]
Message-ID: <878uaybktx.fsf@gmail.com> (raw)
In-Reply-To: <87h9pmn5fh.fsf@nicolasgoaziou.fr>
Hi Nicolas,
2015ko uztailak 2an, Nicolas Goaziou-ek idatzi zuen:
>
> Hello,
>
> Aaron Ecay <aaronecay@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.fsf@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.fsf@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
next prev parent reply other threads:[~2015-07-02 16:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 8:39 Tangling takes long - profiling and calling R Rainer M Krug
2015-06-15 8:42 ` Rainer M Krug
2015-06-15 18:52 ` Charles C. Berry
2015-06-16 10:29 ` Rainer M Krug
2015-06-15 19:49 ` Nicolas Goaziou
2015-06-16 10:34 ` Rainer M Krug
2015-06-16 11:46 ` Nicolas Goaziou
2015-06-16 12:45 ` Sebastien Vauban
2015-06-16 13:04 ` Nicolas Goaziou
2015-06-16 14:47 ` Rainer M Krug
2015-07-01 14:03 ` Aaron Ecay
2015-07-02 11:51 ` Nicolas Goaziou
2015-07-02 12:52 ` Rainer M Krug
2015-07-02 16:35 ` Aaron Ecay
2015-07-02 18:21 ` Sebastien Vauban
2015-07-02 18:44 ` Rainer M Krug
2015-07-02 18:43 ` Rainer M Krug
2015-07-02 16:11 ` Aaron Ecay [this message]
2015-07-03 13:43 ` Nicolas Goaziou
2015-07-02 18:51 ` Rainer M Krug
2015-06-16 14:42 ` Rainer M Krug
2015-06-16 21:45 ` Nicolas Goaziou
2015-06-17 7:16 ` org version numbers in file - WAS: " Rainer M Krug
2015-06-18 8:13 ` Nicolas Goaziou
2015-06-18 13:25 ` Rainer M Krug
2015-06-18 13:50 ` Nicolas Goaziou
2015-06-23 9:04 ` Rainer M Krug
2015-06-18 14:23 ` Detlef Steuer
2015-06-23 8:45 ` Rainer M Krug
2015-06-23 9:32 ` Detlef Steuer
2015-06-23 10:57 ` Rainer M Krug
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878uaybktx.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
--cc=r.m.krug@gmail.com \
--cc=sva-news@mygooglest.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).