Re: [O] 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/)]
Hi Vasil, vdya...@elvees.com (Дядов Васил Стоянов) writes: > I'll change the patch to ob-core.el to reflect behavior of > org-element-property. Please fill in the form to assign your copyright to the FSF, otherwise we will not be able to take any patch for Org's core. http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt Be patient, the process can take up to 3-4 weeks... :/ Thanks! -- Bastien
Re: [O] 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/)]
Hi, I looked into generated html, not result of org-element-property. But you're right: org-element-property works exactly as you say. I'll change the patch to ob-core.el to reflect behavior of org-element-property. With best regards, Vasil > Of course not. With: > > #+attr_html: alt="big image" width="100%" > file:123.png > > (org-element-property :attr_html (org-element-at-point)) with point at > "file:..." will return ("alt=\"big image\" width=\"100%\"") while on the > following example: > > #+attr_html: alt="big image" width="100%" > > file:123.png > > it will return nil. > >> That is why I think that it is not necessary to make org-babel behavior >> different from org-elements (to dissalow empty lines between #+attr and >> #+results when it searches results block), at least for now. > > Babel behaviour is already slightly different from Elements's. In the > long run it will be necessary to correct this. > >> PS: Is there any good documentation and explanation of org-mode >> internals? I could help a little with rewritting org-babel to use >> org-elements. > > You may have a look at the comments at the start of org-elements.el. At > some point, I will have to write an Info doc about this library, unless > I postpone it until the end of time. > > > Regards,
Re: [O] 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/)]
Hello, vdya...@elvees.com (Дядов Васил Стоянов) writes: > With my patch to ob-core.el org-babel works fine with your suggestion. It > just skips #+attr_...: lines as blank lines (original behaviour of > org-babel is to skip blank lines between #+end_src and #+results, when > it searches results block for updating). My remark about syntax was orthogonal to your patch. I was just pointing out you used a wrong example. Eric Schulte will know better than me about your patch. > Of course, org-babel behavior may be easily changed to dissallow empty > lines between #+attr_...: and #+results:. It would be better, indeed. > But currently org-elements allows next construction: > > , > | #+attr_html: alt="big image" width="100%" > | ^ > | | > | +- several empty lines between attr and file > | | > | v > | file:123.png > ` Of course not. With: #+attr_html: alt="big image" width="100%" file:123.png (org-element-property :attr_html (org-element-at-point)) with point at "file:..." will return ("alt=\"big image\" width=\"100%\"") while on the following example: #+attr_html: alt="big image" width="100%" file:123.png it will return nil. > That is why I think that it is not necessary to make org-babel behavior > different from org-elements (to dissalow empty lines between #+attr and > #+results when it searches results block), at least for now. Babel behaviour is already slightly different from Elements's. In the long run it will be necessary to correct this. > PS: Is there any good documentation and explanation of org-mode > internals? I could help a little with rewritting org-babel to use > org-elements. You may have a look at the comments at the start of org-elements.el. At some point, I will have to write an Info doc about this library, unless I postpone it until the end of time. Regards, -- Nicolas Goaziou
Re: [O] 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/)]
vdya...@elvees.com (Дядов Васил Стоянов) writes: > PS: Is there any good documentation and explanation of org-mode > internals? We don't have anything specific, the documentation of org-mode internals is... in the code itself :) -- Bastien
Re: [O] 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/)]
Hi, Nicolas Goaziou writes: > Affiliated keywords have to be put above elements they refer to, without > a blank line in-between. Ok. > 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 With my patch to ob-core.el org-babel works fine with your suggestion. It just skips #+attr_...: lines as blank lines (original behaviour of org-babel is to skip blank lines between #+end_src and #+results, when it searches results block for updating). Of course, org-babel behavior may be easily changed to dissallow empty lines between #+attr_...: and #+results:. But currently org-elements allows next construction: , | #+attr_html: alt="big image" width="100%" | ^ | | | +- several empty lines between attr and file | | | v | file:123.png ` That is why I think that it is not necessary to make org-babel behavior different from org-elements (to dissalow empty lines between #+attr and #+results when it searches results block), at least for now. PS: Is there any good documentation and explanation of org-mode internals? I could help a little with rewritting org-babel to use org-elements. With best regards, Vasil
Re: [O] 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/)]
vdya...@elvees.com (Дядов Васил Стоянов) writes: > Why syntax is invalid? 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 > | > | #+results[f8f8...]: > | #+attr_html: alt="big image" width="100%" > | file:123.png > ` > > C-c C-c, result: > > , > | #+begin_src ditaa :file 123.png :cache yes > | ... > | #+end_src > | > | #+results[f8f8...]: > | file:123.png > | > | #+attr_html: alt="big image" width="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, -- Nicolas Goaziou
Re: [O] 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/)]
Why syntax is invalid? 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 | | #+results[f8f8...]: | #+attr_html: alt="big image" width="100%" | file:123.png ` C-c C-c, result: , | #+begin_src ditaa :file 123.png :cache yes | ... | #+end_src | | #+results[f8f8...]: | file:123.png | | #+attr_html: alt="big image" width="100%" | file:123.png ` With best regards, Vasil
Re: [O] 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/)]
Hello, vdya...@elvees.com (Дядов Васил Стоянов) writes: > Remember to cover the basics, that is, what you expected to happen and > what in fact did happen. You don't know how to make a good report? See > > http://orgmode.org/manual/Feedback.html#Feedback > > Your bug report will be posted to the Org-mode mailing list. > > > With current org-babel it is not possible to set separate html > attributes for result block. > > Simple case: > > , > | #+begin_src ditaa :file 123.png :cache yes > | ... > | #+end_src > | > | #+results[f8f8...]: > | file:123.png > ` > > Suppose, I want to add some html attributes to image: > > , > | #+begin_src ditaa :file 123.png :cache yes > | ... > | #+end_src > | > | #+attr_html: alt="big image" width="100%" > | > | #+results[f8f8...]: > | file:123.png > ` This is an invalid syntax. Attributes lines have to be sticked to the element they refer to. It is true for every element in an Org buffer, not only src blocks. Regards, -- Nicolas Goaziou
[O] 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/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. With current org-babel it is not possible to set separate html attributes for result block. Simple case: , | #+begin_src ditaa :file 123.png :cache yes | ... | #+end_src | | #+results[f8f8...]: | file:123.png ` Suppose, I want to add some html attributes to image: , | #+begin_src ditaa :file 123.png :cache yes | ... | #+end_src | | #+attr_html: alt="big image" width="100%" | | #+results[f8f8...]: | file:123.png ` But when I do C-c C-c on ditaa block, it inserts one more result block: , | #+begin_src ditaa :file 123.png :cache yes | ... | #+end_src | | #+results[f8f8...]: | file:123.png | | #+attr_html: alt="big image" width="100%" | | #+results[f8f8...]: | file:123.png ` Because org-babel does not skip #+attr_ ... lines when searching results block with `org-babel-where-is-src-block-result' function. I've added skipping every #+attr_ line between #+end_src and #+results blocks. Patch is attached. diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 9e4c8b1..00fd715 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -1761,6 +1761,12 @@ following the source block." (progn ;; unnamed results line already exists (re-search-forward "[^ \f\t\n\r\v]" nil t) (beginning-of-line 1) +(while (looking-at-p "[ \t]*\\#\\+[Aa][Tt][Tt][Rr]_") + (end-of-line 1) + (setq end (point)) + (re-search-forward "[\n\r]" nil t) + (re-search-forward "[^ \f\t\n\r\v]" nil t) + (beginning-of-line 1)) (looking-at (concat org-babel-result-regexp "\n"))) (prog1 (point) Emacs : GNU Emacs 24.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.18.9) of 2012-12-25 on canopus-pc.elvees.com Package: Org-mode version 7.9.3d (release_7.9.3d-834-g60083a.dirty @ /home/vdyadov/Work/Tools/emacs/org-mode/lisp/)