From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by sourceware.org (Postfix) with ESMTPS id 7789438618E2 for ; Mon, 28 Sep 2020 13:44:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7789438618E2 Received: by mail-wm1-x341.google.com with SMTP id e2so1219569wme.1 for ; Mon, 28 Sep 2020 06:44:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vrcgimGURFP08wSMl81UQn6m/E7euOVQrOCiFpnBRhY=; b=HKVgMx8L+qCClXS9FuHam2Rfgy0spCUCqD0z153WX4WRH42NBz46i2Iu3a9uWDfb6X Nv3I1zpo7lZyqDDuYP4gBOYtxLSspv9g3bDoql/GmwQfQ8U/CBACMAhh3/AaSXh9g9eS wq/V9dcWrkRlTWHA8ns5jO6GqKkSGm2bM/KWA9yTx6XPPPepDQ0UxUrsJKzUuQ78S1km Evv+uw6oj1m68sI6NtIwgrftLrvzVkZk8SHRt0/u2mOL3bYv20rY38p8OSQzaTOv9iMK pZ9KxDltaYtL0UV96BQpJrYU1pKrTVQVysvnOiKOz7/QOijgummWUZTPiPsQzW3kAOEr sAZQ== X-Gm-Message-State: AOAM532DoeHJPlU993xByenfwxzkNUXaHdfb9c6UMRQVo9D4PUyQRubo Nj6XNbQFG2PNzwi6WWbZc4XmHmG9Eb8= X-Google-Smtp-Source: ABdhPJyMzhF+yk3OqV/znADkZE8T8LIu3dha0w+VmhzsX9Ub2DDfobHBpQrro+2N8sqIoIT7zbhoCw== X-Received: by 2002:a1c:ed19:: with SMTP id l25mr1745892wmh.49.1601300688334; Mon, 28 Sep 2020 06:44:48 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id n21sm1363215wmi.21.2020.09.28.06.44.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Sep 2020 06:44:47 -0700 (PDT) Subject: Re: [PATCH v2 1/3] system_data_types.7: ffix To: "G. Branden Robinson" Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org, libc-alpha@sourceware.org References: <836b6d7d-4433-18d0-78aa-542c419c02f2@gmail.com> <20200928090322.2058-1-colomar.6.4.3@gmail.com> <20200928130558.4qi6jitfwxg6ccm7@localhost.localdomain> From: Alejandro Colomar Message-ID: <1fe937db-8874-a8fb-5e65-88b4b15702fe@gmail.com> Date: Mon, 28 Sep 2020 15:44:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200928130558.4qi6jitfwxg6ccm7@localhost.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 13:44:53 -0000 Hi Branden & Michael, On 2020-09-28 15:06, G. Branden Robinson wrote: > Hi Alex! > > At 2020-09-28T11:03:23+0200, Alejandro Colomar wrote: >> Normally, text under a section header starts in the next line after >> the header, without a blank line. Follow that pattern. > > I think your terminology could confuse some people. A section heading > in a man page is what is typeset by the .SH macro. For instance, ".SH > Name", ".SH See also", and so forth[1]. > > In the below, "aiocb" (in italics) is properly termed a "paragraph tag", > hence the mnemonic for the macro right before it: "TP" for "tagged > paragraph". > > Just FYI. I did mean .SH: For each type we're separating the paragraphs by description, conforming to, see also, ... similar to the .SH sections. And therefore, I thought that we should use the same format for consistency: After the title, or in this case the tag, there should be no blank line. However, if using .br is a big headache, I would rather not use workarounds (as you proposed in an earlier email), and instead just live with the blank line. It's not much of a problem. But Michael did already apply the patch (was it by mistake? or did you agree with the patch, Michael?) I leave it up to you to decide what to do, Michael. My proposals: If you prefer consistency in the source, I'd rather not use workarounds: I'd just leave .PP, and accept the blank line I see those workarounds uglier than .br. If you however prefer consistency in the visual page, I'd use .br, or something that doesn't look like a workaround. Regards, Alex > > [...] >> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 >> index 361e8d411..ff0403df9 100644 >> --- a/man7/system_data_types.7 >> +++ b/man7/system_data_types.7 >> @@ -66,7 +66,7 @@ system_data_types \- overview of system data types >> .TP >> .I aiocb >> .RS >> -.PP >> +.br >> Include: >> .IR . >> .PP >> @@ -101,7 +101,7 @@ See also: > > Regards, > Branden > > [1] Often section headings are written in full capitals in man page > source documents, which loses information. The next release of groff > will feature support for mixed-case section headings with optional > full-caps rendering under user control. >