From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Hendy Subject: Re: exporting documents w/ babel results w/o evaluating babel blocks Date: Fri, 20 May 2016 12:25:40 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3oBC-0005Vv-E8 for emacs-orgmode@gnu.org; Fri, 20 May 2016 13:25:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b3oBB-0002Jw-AU for emacs-orgmode@gnu.org; Fri, 20 May 2016 13:25:42 -0400 Received: from mail-vk0-x236.google.com ([2607:f8b0:400c:c05::236]:33439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3oBB-0002Jr-4h for emacs-orgmode@gnu.org; Fri, 20 May 2016 13:25:41 -0400 Received: by mail-vk0-x236.google.com with SMTP id z184so152172323vkg.0 for ; Fri, 20 May 2016 10:25:41 -0700 (PDT) In-Reply-To: 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" To: Ken Mankoff Cc: "emacs-orgmode@gnu.org" On Fri, May 20, 2016 at 11:45 AM, Ken Mankoff wrote: > > Eric: You're running something newer (by date) than the commit which changed the behavior, which was: > > ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28) > > But with all the branches in git, I don't know if you have that commit or not. Anyway, I'm not sure why it works for you. It doesn't appear to work for John and I the way it used to. Do you have a global "eval: no" set somewhere? > > On 2016-05-20 at 12:14, John Hendy wrote: >> On Fri, May 20, 2016 at 10:57 AM, Ken Mankoff wrote: >>> As of an Org git commit a few weeks ago, Org exporting (and therefore >>> Org) has become basically unusable for me. I used to be able to >>> export code block results without evaluating the block during the >>> export. I can no longer do this. >>> >> >> Well, you're exporting them at least *once*, right? If not, where are >> the results coming from? > > Yes, but only once. Or sometimes I generate the figure elsewhere (via org-edit-special) and then manually put [[file:fig.pdf]] below the #+RESULTS:. > >> I do the same as I'm tweaking plots. Every code block I create has >> :eval yes initially and once I'm satisfied with the results I just >> change to :eval no and the generated results (for me, typically a >> #+results line containing a link to a pdf plot generated by my code >> block) are still included. >> >> Does this help at all? Sorry if I'm not understanding > > You understand, and this sort-of helps. I have never used :eval before. Things just didn't evaluate by default, and I like it like that. > > ":eval no" fixes the problem at export, but then I can't evaluate the code myself manually when not exporting. Not in the buffer so as to replace results, but you *can* go into interactive mode (if python has one) with =C-c '=. I use this constantly, which allows me to ignore whatever :eval is set to, and just putz around in the new code block buffer to my heart's content. I'm approx. 100% R usage, so this still gives me access to the R pop-up device to view plots or an R buffer to see results. You're right though, there's no way to update the results block without toggling :eval, manually running, and then resetting :eval back to no. John > >> Mine is set to t. Interestingly, when I export the above after >> deleting the results bit, no new results are generated. When I C-c >> C-c, they are replaced. When I add :eval no, it does't appear to run >> the code. > > Yes same here. This new behavior really sucks. > > I'm still trying to find a way where: > + code results do export > + code does not export > + code does not evaluate at export > + code can still be evaluated by me > > This was the behavior prior to > > ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28) > > But not since. > > -k.