From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 4P7QHX+g5F7GPwAA0tVLHw (envelope-from ) for ; Sat, 13 Jun 2020 09:46:39 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id QLC0GX+g5F6LdgAAB5/wlQ (envelope-from ) for ; Sat, 13 Jun 2020 09:46:39 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C9B2C94030A for ; Sat, 13 Jun 2020 09:46:38 +0000 (UTC) Received: from localhost ([::1]:48924 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jk2kH-0004Gn-1D for larch@yhetil.org; Sat, 13 Jun 2020 05:46:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jk2jr-0004Ey-Ni for emacs-orgmode@gnu.org; Sat, 13 Jun 2020 05:46:11 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:41005) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jk2jp-0006B2-Cg for emacs-orgmode@gnu.org; Sat, 13 Jun 2020 05:46:11 -0400 Received: from localhost (40-67.ipv4.commingeshautdebit.fr [185.131.40.67]) (Authenticated sender: admin@nicolasgoaziou.fr) by relay11.mail.gandi.net (Postfix) with ESMTPSA id E0458100002; Sat, 13 Jun 2020 09:46:04 +0000 (UTC) From: Nicolas Goaziou To: John Ciolfi Subject: Re: Bug: Option to disable evaluation of code blocks during export [9.3.7 (9.3.7-dist @ /PATH/TO/org/install/emacs/site-lisp/org/)] References: <87wo4di96o.fsf@nicolasgoaziou.fr> <87sgf0is40.fsf@nicolasgoaziou.fr> Mail-Followup-To: John Ciolfi , "emacs-orgmode\@gnu.org" Date: Sat, 13 Jun 2020 11:46:03 +0200 In-Reply-To: (John Ciolfi's message of "Fri, 12 Jun 2020 14:32:26 +0000") Message-ID: <87imfvguxw.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=217.70.178.231; envelope-from=mail@nicolasgoaziou.fr; helo=relay11.mail.gandi.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/13 05:46:06 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "emacs-orgmode@gnu.org" Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: aflH46advlYK Hello, John Ciolfi writes: > Perhaps, in the interactive C-c C-e mode there could be: > > [C-e] Eval code blocks: always | never | use-eval-header-setting > > where 'use-eval-header-settings' is the default and uses whatever was > set by the current org file and emacs session. Always and never would > override that. As I said, this would add an indirection level to an already complicated topic. Moreover, toggles in the export interface are never duplicates from in-buffer settings, so far. This would set a precedent, and might be a sign that this isn't right. > Consider the scenario where a number of people are working on a common > overall "book" which is constructed from many org-files. The > "hardcoded" setting of :eval no-export header in individual blocks > would mean that I cannot interactively enable or disable the > evaluation of the blocks. Why would you add :eval no-export to every block in the first place? In this situation, there should be a global setting, which could be overridden locally with appropriate header arguments. Having a global way, even dynamic, to override every setting in the buffer doesn't seem very useful. It is imprecise; some blocks could still be used to set up export process. I assume there's a good reason if a source code block specifies :eval yes. > Part of my confusion was that it took a little bit to figure this out > (I ended up debugging the lisp code to get what I wanted). I think > this could be improved in the doc, though I do admit, I'm not entirely > clear on all the ways to control evaluation of code blocks during > export. If I were, I'd propose something for the org manual. I think the starting point is in (info "(org) Exporting Code Blocks"). Improvements to the manual are welcome, of course. Regards, -- Nicolas Goaziou