From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniele Pizzolli Subject: Re: babel result chain outdated/inconsistent using var Date: Wed, 06 Apr 2016 15:27:46 +0200 Message-ID: <877fgazzzzsw8d@me.localhost.invalid> References: <87k2kbzzzzrlna@me.localhost.invalid> <87zit6c2y6.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37308) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1annUx-0004CT-GF for emacs-orgmode@gnu.org; Wed, 06 Apr 2016 09:27:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1annUt-0000dN-FW for emacs-orgmode@gnu.org; Wed, 06 Apr 2016 09:27:55 -0400 Received: from relay2-d.mail.gandi.net ([2001:4b98:c:538::194]:37616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1annUt-0000dH-8X for emacs-orgmode@gnu.org; Wed, 06 Apr 2016 09:27:51 -0400 In-Reply-To: <87zit6c2y6.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Wed, 06 Apr 2016 14:54:41 +0200") 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: Nicolas Goaziou Cc: Org-mode On Wed, Apr 06 2016, Nicolas Goaziou wrote: > Hello, > > Daniele Pizzolli writes: > >> is possible to update the =E2=80=9C#+RESULTS: pid=E2=80=9D when the bloc= k =E2=80=9C#+NAME: >> echo-pid=E2=80=9D is evaluated in the following snippet? > > Without `org-babel-execute-buffer', I don't think so. Hello, Thanks Nicolas for the reply. Ok, but `org-babel-execute-buffer' produces an inconsistent document right now. >> This will lead to a consistent document generation with =E2=80=9CM-x >> org-babel-execute-buffer=E2=80=9D or by hitting =E2=80=9CC-c C-c=E2=80= =9D on =E2=80=9C#+NAME: >> echo-pid=E2=80=9D. > > I'm not convinced that this behaviour should be enforced. If I C-c C-c > on a block, I expect only the results of the block to be updated, not > some other part of the document I am editing. Mmm, the same reasoning can be used for arguing about the current behaviour: If I C-c C-c on a block, I expect only the code of the block to be executed, not some other part of the document I am editing. This behaviour will fix my issue. I agree that neither case should be enforced, but the user should be in charge to choose. A reasonable default behaviour will be to not re-execute the other code block if the previous result is already present. > Also, what if the other block is in another document? I don't think it > should be updated either. But should it be either executed? > What is the harm in using `org-babel-execute-buffer' for your use case? Right now it does not produce a consistent document, that should be desirable. I do not have a strong preference about the solution (reuse without re-execute, or update the other result) but for sure, right now there is no way to produce a consistent document. I tried for a workaround, adding `:eval query' #+NAME: pid #+BEGIN_SRC shell :results value :cache no :eval query printf '%s' "${$}" #+END_SRC and then discarding the execution, but instead of reusing the actual result it pass `nil'... no luck. Thanks again, Daniele