From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id fbf14078 for ; Fri, 13 Nov 2015 00:53:02 -0500 (EST) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 9A29820E3; Fri, 13 Nov 2015 05:53:00 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 591E13FB7D; Fri, 13 Nov 2015 06:52:57 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ingo Schwarze Cc: discuss@mdocml.bsd.lv Subject: Re: Mdocdate References: <86r3jva7s9.fsf@desk.des.no> <20151112213135.GL20023@athene.usta.de> Date: Fri, 13 Nov 2015 06:52:57 +0100 In-Reply-To: <20151112213135.GL20023@athene.usta.de> (Ingo Schwarze's message of "Thu, 12 Nov 2015 22:31:35 +0100") Message-ID: <86r3jua1ja.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ingo Schwarze writes: > Dag-Erling Sm=C3=B8rgrav writes: > > - in a2time(): > >=20 > > Skip past "$Mdocdate: " if it exists instead of relying on the > > caller to specify it in the format string. > No, that would introduce a bug. The format is different depending > on whether or not Mdocdate is used. Maybe deplorable, but about a > decade too late to change. Well, it could be changed with a lot of > churn in the tree, but for what benefit? People don't need to type > in the Mdocdate format manually, after all, and even if they do that > and get it wrong, cvs(1) will helpfully fix it for them. I would argue that's a feature. My version will accept several different formats for $Mdocdate$, including both the existing OpenBSD format and the format which is possible to achieve with Subversion. > > Accept trailing text after a successful match (e.g. "$"). > Why? That seems like a step backwards, weakening syntax validation. Postel's law. In this situation, you're not going for strict validation, but for maximum flexibility. You want to give the author the benefit of the doubt, as long as you're reasonably sure that what you saw is a date. > > If the first character after a successful match is 'Z', use UTC > > instead of the local time zone. > That makes no sense. Neither .TH nor .Dd syntax allows time formats > more fine-grained than days, so it makes no sense to worry about > time zones. It can make a difference of =C2=B1 1 day if a) the commit date was close to midnight or b) you are relatively close to the date line. Subversion timestamps are always in UTC and include the time followed by a Z. > > - in mandoc_normdate(): > >=20 > > Fix several logic errors (inverted tests), > Err, what? Can you be more specific? I don't see any logic errors > in there. But your changes break several features. Please explain how if (valid_date(str)) /* we didn't find a valid date */ ; is a feature. > > add a test for the Subversion %d format, > That is not valid mdoc(7) .Dd syntax, so it can't be added. Says who? Once again: Postel's law. > > - in the man page: > > Document how to use Mdocdate with Subversion. > No. Please don't introduce yet another format, use something like > > Mdocdate=3D"%b %d %Y " > > or whatever the subversion syntax is for svn:keywords. That's not possible. Mdocdate=3D%d is the closest you will get, otherwise I wouldn't have needed this patch. > > Given the following test cases: > > [...] > These are all invalid and must generate a warning. > [...] > These are valid, but not with Mdocdate. > [...] > Invalid. > [...] > Valid, but not with Mdocdate. > [...] > Invalid. Once again: who says these dates shouldn't be accepted? Is there some sort of EU directive I'm not aware of that dictates the precise syntax of a .Dd statement in an mdoc file? >> The current code (1.13.3) produces the following output: >>=20 >> % while read d ; do echo ".Dd $d" | mandoc | tail -1 ; done > February 7 2036 >> February 7 2036 >> February 07 2036 >> February 7, 2036 >> February 7, 2036 >> February 7, 2036 >> Feb 7 2036 >> Feb 7 2036 >> Feb 07 2036 >> February 7, 2036 >> February 7, 2036 >> February 7, 2036 >> 2036-02-07 >> 2036-02-7 >> 2036-2-07 >> 2036-2-7 >> February 7, 2036 >> $Mdocdate: 2036-02-07 06:28:16Z $ > > Yes, that is correct behaviour. Not according to what you wrote earlier (the %Y-%m-%d forms should have been accepted but were not due to the logic bugs I mentioned which you claim are not bugs) I must say I'm really surprised by your attitude. You seem to value rigid adherence to forty-year-old specifications over flexibility, ease of use and compatibility with third-party systems, even when the latter can be achieved without sacrificing the former. That's laudable when you're implementing TLS or a message parser in a SOLAS system, but not when you're writing a text preparation system. You'll just end up driving even more people away from mdoc and towards DocBook or Doxygen or whatever the flavor of the month is, for absolutely no benefit. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv