From nobody Sun Jul 25 11:03:24 2021 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5CF3A33E6; Sun, 25 Jul 2021 11:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 prVFEH_52x7i; Sun, 25 Jul 2021 11:03:19 -0700 (PDT) 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 B6C823A3395; Sun, 25 Jul 2021 11:03:19 -0700 (PDT) Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (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 4GXrWm4cNMz2xJf; Sun, 25 Jul 2021 20:03:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: Date: Sun, 25 Jul 2021 20:03:16 +0200 Cc: xml2rfc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4304B0FD-607D-415F-A44C-FE8139C6612D@tzi.org> References: <8424B564-47E1-4655-98D3-D9D29D144ECB@tzi.org> To: Kesara Rathnayake X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [xml2rfc] Outdenting sourcecode X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2021 18:03:23 -0000 On 23. Jul 2021, at 05:33, Kesara Rathnayake = wrote: >=20 >=20 >=20 > On 22/07/21 7:38 pm, Carsten Bormann wrote: >> When I was younger, xml2rfc outdented artwork that was too wide, = giving us a whopping three characters more horizontal space. >> I still get messages that it does, and it sometimes actually does, = but then there are cases where it doesn=E2=80=99t. >=20 > Do you have an example where xml2rfc outdented artwork CDATA? As I said, it never outdents the artwork itself, but it does remove the = additional indent of 3 characters. (And it doesn=E2=80=99t make a difference whether the artwork is CDATA = or #PCDATA.) >> Before I go on a goose chase: What=E2=80=99s going on here? >> (I use xml generated with kramdown-rfc 1.5.2 from = https://github.com/ietf-rats-wg/basic-yang-module/blob/master/draft-ietf-r= ats-yang-tpm-charra.md >> Yes, one can argue how wise it is to have artwork sources indented by = four spaces and relying on xml2rfc to reduce its own indent by three so = everything just fits, but that=E2=80=99s the way it used to work, and I = don=E2=80=99t see how that broke.) >=20 > This could be down to how pretty_print in lxml prints CDATA because = pretty_print_prep function in xml2rfc doesn't seem to be doing anything = on CDATA. Again, this has nothing to do with CDATA and all with computing indents. Normally, when xml2rfc outdents, you get a message, but not in all cases = of the above file. Gr=C3=BC=C3=9Fe, Carsten