[Rfc-markdown] 1.5.22, 1.5.23: {::include ...} variants

Carsten Bormann <cabo@tzi.org> Fri, 17 December 2021 15:53 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rfc-markdown@ietfa.amsl.com
Delivered-To: rfc-markdown@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697AB3A00E0 for <rfc-markdown@ietfa.amsl.com>; Fri, 17 Dec 2021 07:53:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STX283areqSB for <rfc-markdown@ietfa.amsl.com>; Fri, 17 Dec 2021 07:53:42 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1293A0063 for <rfc-markdown@ietf.org>; Fri, 17 Dec 2021 07:53:41 -0800 (PST)
Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JFtnH5CmYzDCcW; Fri, 17 Dec 2021 16:53:39 +0100 (CET)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mao-Original-Outgoing-Id: 661449219.0043271-ee376a676d7529ea53fa91031fd7d63e
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Fri, 17 Dec 2021 16:53:39 +0100
Message-Id: <CF5856AA-E059-4969-A7A7-9B6EEA3EBB93@tzi.org>
To: rfc-markdown@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/sYIDErZ1ziwUC9E7DTGizGUoT54>
Subject: [Rfc-markdown] 1.5.22, 1.5.23: {::include ...} variants
X-BeenThere: rfc-markdown@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "rfc-markdown is a discussion list for people writing I-Ds and RFCs in Markdown and the authors of the tools used for that." <rfc-markdown.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-markdown/>
List-Post: <mailto:rfc-markdown@ietf.org>
List-Help: <mailto:rfc-markdown-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Dec 2021 15:53:48 -0000

For those who wonder about my most recent message:

Since 1.5.22, kramdown-rfc can RFC-8792-fold your {::include …} sections for you, which is most useful in code blocks (~~~~ … ~~~~).
Just say {::include-fold …} and say bye-bye to messages about too-long lines.
Popular combinations like {::include-last-fold foo@????-??-??.yang} should work, too.

Since 1.5.23, kramdown-rfc can include-process included files, just use {::include-nested …}.  This is not recursive, so an included file that wants to include further files will need to use {::include-nested …} too.
Again, combine with other include options to your heart’s content.

Grüße, Carsten