From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: Multiple (identical) RESULTS blocks of one code block? Date: Tue, 10 Mar 2015 14:31:33 +0100 Message-ID: References: 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]:33960) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVKGQ-00029Y-1x for emacs-orgmode@gnu.org; Tue, 10 Mar 2015 09:32:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVKGM-0003jI-8v for emacs-orgmode@gnu.org; Tue, 10 Mar 2015 09:32:01 -0400 Received: from plane.gmane.org ([80.91.229.3]:49364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVKGL-0003j1-SJ for emacs-orgmode@gnu.org; Tue, 10 Mar 2015 09:31:58 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YVKGG-0003zq-7s for emacs-orgmode@gnu.org; Tue, 10 Mar 2015 14:31:52 +0100 Received: from arn78-1-88-186-171-7.fbx.proxad.net ([88.186.171.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Mar 2015 14:31:52 +0100 Received: from Rainer by arn78-1-88-186-171-7.fbx.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Mar 2015 14:31:52 +0100 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: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable John Kitchin writes: > weird. I swear it worked in the little toy problem I made ;) > > I think this is a more robust function: > > #+BEGIN_SRC emacs-lisp > (defun update-results () > ;; get name of src block > (let* ((name (org-element-property :name (org-element-at-point))) > (results (save-excursion > (goto-char (org-babel-find-named-result name)) > (forward-line) > (buffer-substring > (point) (org-element-property :end (org-element-at-poi= nt))))) > (begin)) > (save-excursion > (goto-char (point-min)) > (while (setq begin (org-babel-find-named-result name (point))) > (goto-char begin) > (forward-line) > (setf (buffer-substring > (point) > (org-element-property :end (org-element-at-point))) > results))))) > #+END_SRC > > I tested this one on two examples ;) And also on my example... Thanks John Works perfectly - added to my emacs.org. Any chance that you could put this into a patch so that it could go into or= g? Rainer > > Rainer M Krug writes: > >> Rainer M Krug writes: >> >>> John Kitchin writes: >>> >>>> I don't believe this is possible out of the box. The first RESULTS blo= ck >>>> from the beginning of the buffer will be updated, and not the others. >>>> >>>> You might be able to use a hook function to do this, something like: >>>> >>>> #+BEGIN_SRC emacs-lisp >>>> (defun update-results () (interactive) >>>> ;; get name of src block >>>> (let ((name (org-element-property :name (org-element-at-point))) >>>> (results)) >>>> (when name >>>> (org-element-map (org-element-parse-buffer) 'fixed-width >>>> (lambda (object) >>>> (if results >>>> ;; replace value in block >>>> (setf >>>> (buffer-substring >>>> (org-element-property :begin object) >>>> (org-element-property :end object)) >>>> results) >>>> ;; set results >>>> (setq results >>>> (buffer-substring >>>> (org-element-property :begin object) >>>> (org-element-property :end object))))))))) >>>> #+END_SRC >>>> #+BEGIN_SRC emacs-lisp >>>> (add-hook 'org-babel-after-execute-hook 'update-results) >>>> #+END_SRC >>>> >>>> This worked on a small test example, but I did not test it >>>> thoroughly. your mileage might vary ;) >>> >>> This looks nice - I will try it out and see how it goes. >> >> >> I don't get it to work. >> >> I put the following into my emacs.org and evaluated it: >> >> --8<---------------cut here---------------start------------->8--- >> (defun rmk/update-multiple-results-blocks () (interactive) >> ;; get name of src block >> (let ((name (org-element-property :name (org-element-at-point))) >> (results)) >> (when name >> (org-element-map (org-element-parse-buffer) 'fixed-width >> (lambda (object) >> (if results >> ;; replace value in block >> (setf >> (buffer-substring >> (org-element-property :begin object) >> (org-element-property :end object)) >> results) >> ;; set results >> (setq results >> (buffer-substring >> (org-element-property :begin object) >> (org-element-property :end object))))))))) >> >> #+end_src >> >> #+RESULTS: >> : rmk/update-multiple-results-blocks >> >> Add this function to =3Dorg-babel=3Dafter-execute-hook=3D >> #+begin_src emacs-lisp >> (add-hook 'org-babel-after-execute-hook 'rmk/update-multiple-results-blo= cks) >> #+end_src >> >> #+RESULTS: >> | rmk/update-multiple-results-blocks | >> --8<---------------cut here---------------end--------------->8--- >> >> >> I am using the following org file to test it: >> >> --8<---------------cut here---------------start------------->8--- >> * The calculation >> #+NAME: testcode >> #+begin_src R :session test >> runif(10) >> #+end_src >> >> * summary of the results >> First time >> #+RESULTS: testcode >> | 0.471471928292885 | >> | 0.128247044514865 | >> | 0.398714824113995 | >> | 0.335577708436176 | >> | 0.0184990330599248 | >> | 0.952211205149069 | >> | 0.367342215497047 | >> | 0.581879974342883 | >> | 0.440492485417053 | >> | 0.0729096119757742 | >> >> >> #+RESULTS: testcode >> | 0.0095007149502635 | >> | 0.0898537992034107 | >> | 0.764667606214061 | >> | 0.0309854068327695 | >> | 0.510338442632928 | >> | 0.220906731439754 | >> | 0.589271233882755 | >> | 0.966699115466326 | >> | 0.0183747289702296 | >> | 0.734954049577937 | >> --8<---------------cut here---------------end--------------->8--- >> >> But only the first results block is updated. The function >> =3Drmk/update-multiple-results-blocks=3D is executed. >> >> I am using >> >> ,---- >> | Org-mode version 8.3beta (release_8.3beta-884-g9ed426 @ /Users/rainerk= rug/.emacs.d/org-mode/lisp/) >> | GNU Emacs 24.4.1 (x86_64-apple-darwin14.0.0, Carbon Version 157 >> | AppKit 1343.16) of 2015-02-02 on Rainers-MacBook-Pro-4.local >> `---- >> >> Any ideas what is going wrong? >> >> Thanks, >> >> Rainer >> >> >>> >>> >>>> >>>> >>>> Rainer M Krug writes: >>>> >>>>> Hi >>>>> >>>>> Consider the following: >>>>> >>>>> --8<---------------cut here---------------start------------->8--- >>>>> * The calculation >>>>> #+NAME: testcode :exports both >>>>> #+begin_src R :session test >>>>> runif(10) >>>>> #+end_src >>>>> >>>>> >>>>> * summary of the results >>>>> First time >>>>> #+RESULTS: testcode :exports both >>>>> | 0.772744940361008 | >>>>> | 0.170518629485741 | >>>>> | 0.0833237133920193 | >>>>> | 0.149035625392571 | >>>>> | 0.698798568220809 | >>>>> | 0.627075897762552 | >>>>> | 0.177144371205941 | >>>>> | 0.0476319056469947 | >>>>> | 0.289851602632552 | >>>>> | 0.0296813279855996 | >>>>> >>>>> * and another >>>>> testthingy >>>>> #+RESULTS: testcode :exports both >>>>> >>>>> --8<---------------cut here---------------end--------------->8--- >>>>> >>>>> If I update the calculation, the first results block is updated, but >>>>> not the second one. I would like to have two RESULTS blocks which >>>>> are both updated when the code block is evaluated. >>>>> >>>>> Is this possible? >>>>> >>>>> Thanks, >>>>> >>>>> Rainer >>>> >>>> -- >>>> Professor John Kitchin >>>> Doherty Hall A207F >>>> Department of Chemical Engineering >>>> Carnegie Mellon University >>>> Pittsburgh, PA 15213 >>>> 412-268-7803 >>>> @johnkitchin >>>> http://kitchingroup.cheme.cmu.edu >>>> >>>> > > -- > Professor John Kitchin > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu =2D-=20 Rainer M. Krug PGP: 0x0F52F982 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBAgAGBQJU/vI6AAoJENvXNx4PUvmCtT8H/25cIPqHjHzeZDNVCnAvceCZ Ig7wqcVhmeCVtjOu6ML/G6k3BEIiFi5NgHzOsG+SbHxIZ/ZOeq/HC1HrdcDtNSuv g+K+oJBpuHQQMjfPjlkurpmY3AOU8cnpNPfn0JyHObYsspDIQ8Yg6mf8usuBFTE5 CFrCLMzuRok9y1o0BTl2iZFtJIiC8E0QtxLUviova5MS/vY/ke/BWj972dzMC1SO vf60fzxercBFIHvulqOJgq0u/YYkIsWAJMlisLWI0oUWxT97mDCtDqkZaQM9Cr1p VnmZ5O0jvKNsCKPSSY4VuE+2ICncIffg42awESB9gMUf8Q6c0l/Lt2GZFWh3Ex0= =hYZb -----END PGP SIGNATURE----- --=-=-=--