From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Bug: [PATCH] Org-babel: separate #+attr_... for code block and for results block [7.9.3d (release_7.9.3d-834-g60083a.dirty @ /home/vdyadov/Work/Tools/emacs/org-mode/lisp/)] Date: Wed, 23 Jan 2013 16:22:24 +0100 Message-ID: <871udbapqn.fsf@gmail.com> References: <87ip6o9h2e.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:49049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ty2A3-00036i-GO for emacs-orgmode@gnu.org; Wed, 23 Jan 2013 10:22:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ty2A1-0006Nv-D4 for emacs-orgmode@gnu.org; Wed, 23 Jan 2013 10:22:47 -0500 Received: from mail-wg0-x229.google.com ([2a00:1450:400c:c00::229]:44694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ty2A1-0006ND-6s for emacs-orgmode@gnu.org; Wed, 23 Jan 2013 10:22:45 -0500 Received: by mail-wg0-f41.google.com with SMTP id ds1so2609068wgb.0 for ; Wed, 23 Jan 2013 07:22:44 -0800 (PST) In-Reply-To: (=?utf-8?B?ItCU0Y8=?= =?utf-8?B?0LTQvtCyINCS0LDRgdC40Lsg0KHRgtC+0Y/QvdC+0LIiJ3M=?= message of "Wed, 23 Jan 2013 19:03:43 +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: =?utf-8?B?0JTRj9C00L7QsiDQktCw0YHQuNC7INCh0YLQvtGP?= =?utf-8?B?0L3QvtCy?= Cc: emacs-orgmode@gnu.org vdyadov@elvees.com (=D0=94=D1=8F=D0=B4=D0=BE=D0=B2 =D0=92=D0=B0=D1=81=D0=B8= =D0=BB =D0=A1=D1=82=D0=BE=D1=8F=D0=BD=D0=BE=D0=B2) writes: > Why syntax is invalid?=20 Affiliated keywords have to be put above elements they refer to, without a blank line in-between. > I've taken a look at the source code in org-elements.el and found that > it is taking into account some expressions, like #+results: and so > on(see org-element-affiliated-keywords, org-element--affiliated-re) > when attaching properties to objects. > > And everything works fine (attributes were attached to right objects), > except org-babel strategy for searching #+results: expression for > updating results. > > What could you suggest in my case? When I put attributes right before > link to the image file, I get: > > initial code: > > ,---- > | #+begin_src ditaa :file 123.png :cache yes > | ... > | #+end_src > |=20=20 > | #+results[f8f8...]: > | #+attr_html: alt=3D"big image" width=3D"100%" > | file:123.png > `---- > > C-c C-c, result: > > ,---- > | #+begin_src ditaa :file 123.png :cache yes > | ... > | #+end_src > |=20=20 > | #+results[f8f8...]: > | file:123.png > |=20 > | #+attr_html: alt=3D"big image" width=3D"100%" > | file:123.png > `---- Elements doesn't care about order for affiliated keywords (here results and attr_html), but Babel, which isn't built on Elements (yet), does. Hence, I suggest: #+attr_html: ... #+results: ... file Regards, --=20 Nicolas Goaziou