From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21524 invoked from network); 13 Oct 2023 11:52:58 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 13 Oct 2023 11:52:58 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id fb0bc550 for ; Fri, 13 Oct 2023 11:52:57 +0000 (UTC) Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id fbc03a00 for ; Fri, 13 Oct 2023 11:52:57 +0000 (UTC) Received: from hekate.asta.kit.edu ([2a00:1398:5:f401::77]) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (envelope-from ) id 1qrGiu-00FWoA-1j; Fri, 13 Oct 2023 13:52:56 +0200 Received: from login-1.asta.kit.edu ([2a00:1398:5:f400::72]) by hekate.asta.kit.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1qrGit-002NGZ-Iu; Fri, 13 Oct 2023 13:52:55 +0200 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.94.2) (envelope-from ) id 1qrGit-00EjCn-BX; Fri, 13 Oct 2023 13:52:55 +0200 Date: Fri, 13 Oct 2023 13:52:55 +0200 From: Ingo Schwarze To: Baptiste Daroussin Cc: tech@mandoc.bsd.lv Subject: Re: Naive patch for handling empty input Message-ID: References: X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Bapt, Baptiste Daroussin wrote on Fri, Oct 13, 2023 at 01:22:41PM +0200: > On Fri, Oct 13, 2023 at 01:05:19PM +0200, Ingo Schwarze wrote: >> Baptiste Daroussin wrote on Fri, Oct 13, 2023 at 12:22:09PM +0200: >>> I was looking for compatibility with groff like you showed above, this >>> is an "issue" a user reported, he was expecting to have an empty output >>> if provided an empty input, but if the current behaviour is how you think >>> mandoc should behave, I am fine with closing the report with work as >>> intended. >> It might be useful to ask the user first *why* they want that >> particular behaviour, and how they think mandoc(1) should behave >> without .TH or .Dd in general, and why they want specific behaviour >> in such cases of degenerate input. >> >> It is conceivable that maybe they have an interesting reason, >> and knowing that reason might help to make mandoc better? >> I'm not sure it will, but i'm not sure that possibility can be >> excluded, either. > I am not sure, the report happened here: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274247 I see, i added an inquiry there, hoping that wosch@ may be able to clarify why he thinks this "Affects Some People". Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv