From: "Dag-Erling Smørgrav" <firstname.lastname@example.org> To: Ingo Schwarze <email@example.com> Cc: firstname.lastname@example.org Subject: Re: Mdocdate Date: Fri, 13 Nov 2015 06:52:57 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20151112213135.GL20023@athene.usta.de> (Ingo Schwarze's message of "Thu, 12 Nov 2015 22:31:35 +0100") Ingo Schwarze <firstname.lastname@example.org> writes: > Dag-Erling Smørgrav <email@example.com> writes: > > - in a2time(): > > > > 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 ± 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(): > > > > 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="%b %d %Y " > > or whatever the subversion syntax is for svn:keywords. That's not possible. Mdocdate=%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: >> >> % while read d ; do echo ".Dd $d" | mandoc | tail -1 ; done <tests >> 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 -- Dag-Erling Smørgrav - firstname.lastname@example.org -- To unsubscribe send an email to email@example.com
next prev parent reply other threads:[~2015-11-13 5:53 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-12 9:25 Mdocdate Dag-Erling Smørgrav 2015-11-12 21:31 ` Mdocdate Ingo Schwarze 2015-11-12 23:06 ` Mdocdate Ingo Schwarze 2015-11-13 5:52 ` Dag-Erling Smørgrav [this message] 2015-11-14 1:22 ` Mdocdate Ingo Schwarze 2015-11-14 15:02 ` Mdocdate Steffen Nurpmeso 2015-11-15 1:51 ` Mdocdate Ingo Schwarze 2015-11-16 13:35 ` Mdocdate Steffen Nurpmeso 2015-11-17 9:12 ` Mdocdate Svyatoslav Mishyn 2015-11-17 10:35 ` Mdocdate Steffen Nurpmeso 2015-11-23 20:48 ` Mdocdate Michael Dexter
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Mdocdate' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).