From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=no autolearn_force=no version=3.4.4 Received: from mandoc.bsd.lv (bsd.lv [66.111.2.12]) by inbox.vuxu.org (Postfix) with ESMTP id 94B7F2241B for ; Wed, 25 Sep 2024 02:18:33 +0200 (CEST) Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 2966d97e for ; Wed, 25 Sep 2024 00:18:31 +0000 (UTC) Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 47f64220 for ; Wed, 25 Sep 2024 00:18:30 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 75C8011401C6 for ; Tue, 24 Sep 2024 20:18:30 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Tue, 24 Sep 2024 20:18:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jklol.net; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1727223510; x=1727309910; bh=0VyMxKRQtAHt6jqx2m5aK5grFjXj95vL3LU3GOfye44=; b= d2u94z2+I50Wv3N2u3GNkVsOozqrCZr42yirkOpeF2yzQ4tuZIV7zQCj3JHR6KBW XO9owp1EOFgL7QL5vDiOn1B3qAspGuuY3QOBexXtN0c96aBtv9SWebqH6KV1mvKo QGZBASGSRu6a5yjbd4ifibaU+cG8z+WRAbVB2HMBc1msYKInVIXILJM7HMbeKHkN xhDiDo+EdFNiWzZG0QNnChpB2fUNuPlckt1XIIC/S1dA6H/0c1lXzDVq/i0pVVCx q80oLFGkRzIX+NZUN6faV1HtHbdrs/i3s3OHrEuM0wHcGg4TPhIH4yoOhwoJYMz1 MJ6MyS1dpXBSju1M7kyCGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1727223510; x= 1727309910; bh=0VyMxKRQtAHt6jqx2m5aK5grFjXj95vL3LU3GOfye44=; b=h 2UzET2ZnNxJO2lRaSo2+E1My/snGVTVj29VZ7cn5F91jT4pCMYytQxCjmIgg0ZCG O8y/7NsQCFvncpjzoyBCWKKIWeiQJ4WytVyuDnR1bxJab4Vl50gVdHQBN9fF51Uk 0oyagPPmjNwfjwDNI/Rou80qdJ8OXsinVwxtNyfIFcJTam0Skx5OhdLTL9mtuB1+ Y5BxJm/iEXgat7c/SERTQWYjqiwM0Y1zqeo4dwzIQcKYoIWpqgBT3AQwsOL96aFR pHiGw5uhKQC0tlRGDgyFRQjWJqsh6poloYX62bh0xzRSEoMdmqqUgxF9CQ0IhuBL t2V47PKGZw1V5jyr3wl/g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddtgedgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeffvffuhf hfjgfkfgggtgfgsehtqhertddtreejnecuhfhrohhmpefgvhgrnhcuufhilhgsvghrmhgr nhcuoegvvhgrnhesjhhklhholhdrnhgvtheqnecuggftrfgrthhtvghrnhephefgtedvhe efvdfgjeetgfdthfdtkeetteeiudffveelleevvefgkeeiffdvvedunecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvghvrghnsehjkhhlohhlrd hnvghtpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtphhtthho peguihhstghushhssehmrghnughotgdrsghsugdrlhhv X-ME-Proxy: Feedback-ID: iba8c40ff:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 24 Sep 2024 20:18:29 -0400 (EDT) Date: Tue, 24 Sep 2024 17:18:28 -0700 To: discuss@mandoc.bsd.lv Subject: befuddled by .Xo/.Xc From: Evan Silberman References: <2EQQ8UJHXJLYT.2H2AM42MNPSXB@silby.fyi> In-Reply-To: <2EQQ8UJHXJLYT.2H2AM42MNPSXB@silby.fyi> Message-Id: <2UKLZW0DL8BSM.2IIO9W4HSUSRR@silby.fyi> User-Agent: mblaze/1.2 X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I just sent the below to tech@openbsd with a patch (snipped). Evan Silberman wrote: > .Xo/.Xc outside an .It header or a block-partial-implicit macro body seem= s to > be a no-op on present mandoc and is not a documented use-case. ascii and > html output are identical before and after. >=20 > If I'm wrong about the above in some way I will appreciate correction, > as I am working on an mdoc(7) parser in another setting, and naturally > mandoc(1) is my reference implementation and the OpenBSD manuals are my > reference corpus. I am crossposting here because I'm realizing that I don't actually understand mdoc(7)'s documentation of what .Xo/.Xc are meant to do outside the limited case of the .It header, and it seems more appropriate to ask here. mdoc(7) reads: > Extend =E2=80=A6 the body of a partial-implicit block macro beyond the en= d of > the input line. My interpretation of this sentence was that these two snippets of markup should be equivalent: =20 .Dq hello, world .Dq hello, Xo world .Xc It can easily be verified that this isn't true. I can find no instances of .Xo outside of .It in OpenBSD's installed manuals that really explain this usage to me. There are the cases where .Xo (on a line by itself)/.Xc just wrap some other stuff, that as far as I could tell were a no-op. The only other examples are from ksh.1, which differ only in that .Xo comes at the end of a control line with some other stuff in it. It seems to be a no-op there too. And it still doesn't clearly demonstrate a particular association with a block-partial-implicit macro. .Sm off .Ao Ar var Ac Xo .Aq Ar op .No =3D Aq Ar expr .Xc .Sm on Finally, .Xo/.Xc is used in a couple mdoc regress tests for (it appears) artificial reasons, to enclose an empty Fl macro with a block that doesn't print anything special. I searched for .Xo in the discuss@ archives and was not particularly enlightened, beyond some evidence that .Xo/.Xc had some special attention paid to it during mandoc's early days. So, I am left with the question: what, if anything, is .Xo/.Xc meant to do outside of an .It header? In mandoc, does it still actually do what it's meant to do? And either way, can a reasonably-accurate mdoc(7) parser just treat it as a no-op? thanks, Evan Silberman -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv