From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: master c86995d07e9: Enable code block evaluation when generating .org manuals Date: Sun, 9 Jun 2024 12:19:42 -0700 Message-ID: References: <171767737644.19678.784876979840850798@vcs2.savannah.gnu.org> <20240606123616.DE7C9C1F9EF@vcs2.savannah.gnu.org> <87h6e6i1mg.fsf@gmail.com> <87sexplbmn.fsf@kyleam.com> <874ja22e7t.fsf@localhost> <87v82i0xc4.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25826"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Kyle Meyer , Robert Pluim , emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 09 21:20:10 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sGO5J-0006Un-Uh for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jun 2024 21:20:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sGO4y-0004iX-8G; Sun, 09 Jun 2024 15:19:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sGO4x-0004iO-17 for emacs-devel@gnu.org; Sun, 09 Jun 2024 15:19:47 -0400 Original-Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sGO4v-0000oD-EX for emacs-devel@gnu.org; Sun, 09 Jun 2024 15:19:46 -0400 Original-Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2ebd95f136bso10877071fa.0 for ; Sun, 09 Jun 2024 12:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717960783; x=1718565583; darn=gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=rRBd/Z36SGaI8uQqNQC5In+rqxOwe+3L++xardK9xVM=; b=fn0kGXKpdfDSDRHkEaCRioKuzIbnMpvX69kMZWCJ/M1bn0tF2wrQCYeUZXJgRe2hQK DjTx4fenP6djusOnvreBA0Jhq5waGXHA0Ryd7oQgnK7QVegLbJEAk9VcE4Y6KI8oGf+t 8SuqKClp8h9jvqS2tK5fCgeD8UOpV3Q9rGXTaSko+yhtql/YU78y9/0NXA6DsaQ2IE+2 LHtcwC8A4QOMeUETwB9xWA5HoMs026+OPH/5e6bOna8FTSl6sMd/UUhXIEcVBMDvAluG OJrTTdtvyUbLR/ZmIVWHyISKuRXzCswli1H4xEAiWMU4P3cgih0MW7fDpIuOAsO2ReWh 9yxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717960783; x=1718565583; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rRBd/Z36SGaI8uQqNQC5In+rqxOwe+3L++xardK9xVM=; b=GOVPHn2885gpRpiF7s095HMNPUrHL7XFRtKPlV1oSiB65vm5OGkeBoMXLBx0GRmmIo 67tTMcLPksuNv8pwtTbSojntcYkRhHWGty8ZWqh3t81e45HBlfj9CInjy7gz+UEFwqro 9nwQ6W7WJvE3wEj6AdnEkPqScEJG2txRQBWpPNAesH7sDvd4kVXKBi/VPg4eL6m5V5xX TsdXFjHgcOfUiEF4Lt5nJAqZl09M5KXDSG2DNiQI8zFyTLbafClx+ehwuF4n34t0tQ5a +F5VlvM7dLW/QpuZBTJptlzUMIiG2a3n6IDE+ppJg0/3Hi177iadSwXyQO7jFB49CGs0 N7Hg== X-Forwarded-Encrypted: i=1; AJvYcCX2OsaWaSw3gpBGeTc+Cc4YGbzE+bN9kzdoRhFbp6pfxv4mXLr5e/UiGyOu/N336O3TrSZQBkQ+cOwFF9uEWW9Woe96 X-Gm-Message-State: AOJu0YxorDIVYl3dAUumf1tilrcSY3Pro6zs0SQJHXwKy+ai1Jzh+qeH HybyQB6ERV1dunsUkwYFOnBapBzvX6ZVrUV8KTFviyjnDHA5W8OePvNwe9qp5fv5wPTaMA5hSa8 P1WP/Cnct+9ztBaQpOpC859fY7nQ= X-Google-Smtp-Source: AGHT+IFwtyLWNbnFyH8BjGVXTvAGg4hb5bcW9UVQUj9/vlrTeKP8vn6VuJRd00pYqWEm/qYW5tTi1QvvYibzHo8UJOc= X-Received: by 2002:a2e:8752:0:b0:2eb:120c:1a59 with SMTP id 38308e7fff4ca-2eb120c1b22mr33529061fa.16.1717960783237; Sun, 09 Jun 2024 12:19:43 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 9 Jun 2024 12:19:42 -0700 In-Reply-To: <87v82i0xc4.fsf@localhost> Received-SPF: pass client-ip=2a00:1450:4864:20::233; envelope-from=stefankangas@gmail.com; helo=mail-lj1-x233.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319940 Archived-At: Ihor Radchenko writes: > It is certainly possible. We would need to run pre-processing and then > generate the final manuals from yet another intermediate pre-processed > .org file. However, I am not sure why would we need to bother with such > extra work. What would be the benefit? I don't consider this urgent or a blocker for merging the latest Org mode release, but the benefit would be to avoid running code from a documentation file on every build. You can, of course, slip in malicious changes anywhere, but it's arguably easier in a documentation file since some of us might relax and think that it's safer since it's "just documentation". Consider, for example, sweeping changes like fixing typos, or reformatting. Now we need to look at such things more closely also when it only concerns documentation fixes. To be clear, all of us are obviously doing the best job we can, and some of us are doing a very fine job indeed, but bugs still can and do slip under our radar. There's nothing unique about malicious code that means that it's somehow impossible for us to miss it. IOW, I don't think I see why we shouldn't try to make our job easier if we can. Hence my question how hard it would be to replicate what we already do for loaddefs files. If it's not practical, then so be it.