From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: Difference :header-args: and :header-args+:? Date: Tue, 09 Sep 2014 10:20:56 +0200 Message-ID: References: <877g1j1gwx.fsf@gmail.com> <87vbp1r1fk.fsf@gmail.com> <87sik29ogv.fsf@Rainer.invalid> <87r3zlrcnt.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRGfo-0000MV-04 for emacs-orgmode@gnu.org; Tue, 09 Sep 2014 04:21:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XRGfg-0006p2-H4 for emacs-orgmode@gnu.org; Tue, 09 Sep 2014 04:21:11 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:51153) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRGfg-0006op-8C for emacs-orgmode@gnu.org; Tue, 09 Sep 2014 04:21:04 -0400 Received: by mail-wi0-f179.google.com with SMTP id q5so3972589wiv.0 for ; Tue, 09 Sep 2014 01:21:03 -0700 (PDT) In-Reply-To: <87r3zlrcnt.fsf@gmail.com> (Aaron Ecay's message of "Mon, 08 Sep 2014 18:05:26 -0400") 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: Achim Gratz Cc: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Aaron Ecay writes: > Hi Achim, > > 2014ko irailak 8an, Achim Gratz-ek idatzi zuen: >>=20 >> Aaron Ecay writes: >>> Eric Schulte has said >>> that the deprecation of this feature is =E2=80=9Cpremature=E2=80=9D. I= didn=E2=80=99t realize >>> at the time that the deprecation was also included in the manual rather >>> than just a code comment. Possibly it should be un-deprecated. >>=20 >> It shouldn't, owing to a number of essentially un-fixable corner cases >> and its inherent non-scaleability. I think that one main confusion comes fro the fact that by the new syntax, the previous properties in the header arguments have been demoted to sub-properties of the real property :header-args. So all operations on :header-args are operations on a *set of properties*. If this is the case, I would opt, in addition to the + operator, to have a - operator, which *removes* properties from the property set :header-args. I would actually call the + an "operation on an already defined property" and it should give an error message if the property is not set yet. So we have a property setter (:header-args) and property operators (header-args+) as well as (hopefully) :header-args-. By using this terminology, and that the property operators can only be called when the property has already been defined (which it usually is due to default values), the usage should be clearer. The same should apply to the :var as it also contains a set of entities. > > Can you say more about the corner cases? I looked for discussion on the > mailing list around the time your changes were introduced. I only found > a message (in a > thread about how/where #+call lines insert their results) that treats > the change as a fait accompli, (=E2=80=9CI agree that this didn't make al= l that > much sense in the past, but with property evaluation and elisp argument > evaluation now anchored to the point of call [...]=E2=80=9D) > > I could have missed something, of course. > > As to the non-scalability, that should be fixed by some combination of > the parser cache and retrieving all properties at once (via > =E2=80=98org-entry-properties=E2=80=99) rather than =E2=80=98org-entry-ge= t=E2=80=99-ing them one-by-one. > There are a couple recent threads about this. Here=E2=80=99s one > about a reimplementation > of the property API functions in terms of the parser. Here > > the speed tradeoffs of the two approaches are discussed. (IOW, as > presently implemented the classical method is not scalable, but said > unscalability is by no means =E2=80=9Cinherent=E2=80=9D.) > >>=20 >>> Certainly I agree that the suggested replacement is less capable. >>=20 >> Do you have an example of something that it cannot do (modulo the bugs >> and corners of the deprecated syntax)? > > See the attached file for two examples, one related to #+call lines and > one not. > > Again, can you say more about what you mean by the bugs and corners of > the deprecated syntax? The #+call behavior doesn=E2=80=99t seem like a b= ug, but > basically a difference in whether header args are dynamically (wrt point > of call) or lexically (wrt point of definition) scoped. Dynamic > vs. lexical scoping is not a bug, but a matter of taste/language > design/etc. Most computer languages with which I=E2=80=99m familiar (Pyt= hon, R, > C, Scheme/Lisp, ...) use lexical scoping by default, and elisp has been > slowly but steadily moving in that direction for years. Thus this new > suggested dynamic-type behavior for header args is surprising to me. > > The first demonstration in the attachment (not related to #+calls) > seems like a much clearer case of deficiency of the new system: an > inability to inherit different args from different levels. (Please > factor away from the nonsense strings in place of =E2=80=9Cyes=E2=80=9D a= nd =E2=80=9Cno=E2=80=9D =E2=80=93 I > wanted to make it clear where each value was coming from, and assure > that they were not being generated by default. Of course in a real use > case the values for these header args would be =E2=80=9Cyes=E2=80=9D and = =E2=80=9Cno=E2=80=9D. Also, > one could also demonstrate the problem with header args that can take > an arbitrary string value by design, like :session.) Initially I thought, to use :header-args+ instead of :header-args would work, but I was wrong (see below). ,---- | *** Subtree | :PROPERTIES: | :header-args+: :cache quux | :END: |=20 | *PROBLEM*: we don=E2=80=99t get =3D:comments foo=3D from parent headline = (=E2=80=9CThe new way=E2=80=9D) |=20 | #+begin_src emacs-lisp | (awe-show-headers :cache :comments) | #+end_src |=20 | #+RESULTS: | : ((:comments . "") | : (:cache . "quux no")) `---- I guess one problem that the properties in :header-args are evaluated From=20left to right, and if one is found, this one is used? In case of inheritance (and adding a property via :header-args+) appends it, and if a same one exists before, the older one is used? > > From your other mail: > > 2014ko irailak 8an, Achim Gratz-ek idatzi zuen: >>=20 >> Rainer M Krug writes: >>> Aaron Ecay writes: > > [...] > >>>> Are you aware that you can set individual header args as properties? >>>> Something like (at the file level): >>=20 >> Are you aware that this doesn't quite do what you think it does, some of >> the time, when things become more complex than your example? > > Again, can you say more about what you mean here? As a personal > anecdote, I have never been surprised by the behavior of =E2=80=9Cclassic= =E2=80=9D > header arg properties. > >>=20 >>> I was using this deprecated behavior and I was *very* happy with it, but >>> I am trying to adjust to the new syntax. >>>=20 >>> So how can I use the new syntax? >>=20 >> If you maybe had an example of what you're trying to do instead of >> asking stuff about things you don't want to do? Otherwise, have a look >> at >>=20 >> /testing/examples/ob-header-arg-defaults.org > > I find the content of this file incredibly dense, and the suggestion > of its use as documentation bordering on a joke. (Documentation may > not exist, and that just means an area for improvement has been found. > But it=E2=80=99s not as though we=E2=80=99re all going to read that file = and suddenly > understand what you mean.) It looks like it is trying to demonstrate > inheritance and overriding of :var header args. I can=E2=80=99t figure o= ut > why the #+call in =E2=80=9COverwrite=E2=80=9D gets go1, but the addition = of =E2=80=9Cvar+ to1=E2=80=9D > in =E2=80=9CAccumulate=E2=80=9D causes this to shift, not to =E2=80=9Cto1= =E2=80=9D, but to =E2=80=9Cge1=E2=80=9D. > That is a very confusing interaction (to name just one). It=E2=80=99s al= so not > clear to me how it relates to other header args, since vars supplement > each other, whereas other types of header replace. I just looked at it - and there are may things going on which are way to complex to understand the basics of the use of :header-args (or rather working with property sets (or lists?) in general?) in org/ A still confused Rainer =2D-=20 Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBAgAGBQJUDrhsAAoJENvXNx4PUvmCYrUH/3bKn0OMK+CunPBwEazxUeY4 2hUm1SEiFgKOxiDPHR2jdQGTaoS1cQ/mt/aPoGKW1lptS6xkpZdGYQL4rZZeKuOu yrrCD6A0g3AQxM3JrO/FP6JKsLe5A+t8NBRvqbkOwrtK9lFN5iehLMV5Vw94T7wd Dsy5KPmmU4Uh/q/LTfvvflViD1ezahHwbYz5u9LFEXri11PM31H2JNfcPajkJN+Y wA8sDi1+acPbwfrtec2gq5BBgEV0Fo81uKejp0mSS3MQZd/yBIfXs4FxBZktWyuB VVs8Nsbq/uUks7DuAG7pOFo0ovOwmRuoqIxvCll137q/U0PxdKfcn0pzI3T7WOk= =CLwE -----END PGP SIGNATURE----- --=-=-=--