From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ey0-f177.google.com (mail-ey0-f177.google.com [209.85.215.177]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id p9A2e0pV022826 for ; Sun, 9 Oct 2011 22:40:01 -0400 (EDT) Received: by eye3 with SMTP id 3so31247eye.36 for ; Sun, 09 Oct 2011 19:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=W5Vn5bbDIKckX3l6YrT1GlRLeRw4ifSQqhPCz2IFQpc=; b=OeyQQWpMyIpFVvW6rKlzjqhbOsxi5QExaW5nMpCqdU4JJVF2z8qRdbJucrITdlWMYI rwXUkLNNLL2aML71malMQtTW2tdE/P19QdaIQaq0k5Oq+wiJiJDHJGcmpYd+2H0QCF8X /scg9zjauS5hTndGpC6MmcVrvnldq1rKMkOD4= Received: by 10.223.58.138 with SMTP id g10mr29059345fah.20.1318214394846; Sun, 09 Oct 2011 19:39:54 -0700 (PDT) Received: from procyon.xvoid.org ([213.132.76.142]) by mx.google.com with ESMTPS id u6sm28821264faf.3.2011.10.09.19.39.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 09 Oct 2011 19:39:53 -0700 (PDT) Received: from procyon.xvoid.org (yuri@procyon.xvoid.org [IPv6:::1]) by procyon.xvoid.org (8.14.5/8.14.5) with ESMTP id p9A2dnHT075500; Mon, 10 Oct 2011 06:39:49 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by procyon.xvoid.org (8.14.5/8.14.5/Submit) id p9A2dicO075499; Mon, 10 Oct 2011 06:39:44 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: procyon.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Mon, 10 Oct 2011 06:39:44 +0400 From: Yuri Pankov To: Ingo Schwarze Cc: discuss@mdocml.bsd.lv Subject: Re: Use OSNAME/uname and msec.in for man(7) input Message-ID: <20111010023944.GI1294@procyon.xvoid.org> References: <20111007211428.GG1294@procyon.xvoid.org> <4E8F7931.7030307@bsd.lv> <20111007222147.GH1294@procyon.xvoid.org> <20111009223332.GF10611@iris.usta.de> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pd0ReVV5GZGQvF3a" Content-Disposition: inline In-Reply-To: <20111009223332.GF10611@iris.usta.de> User-Agent: Mutt/1.5.21 (2010-09-15) --Pd0ReVV5GZGQvF3a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2011 at 12:33:32AM +0200, Ingo Schwarze wrote: > Hi Yuri, >=20 > Yuri Pankov wrote on Sat, Oct 08, 2011 at 02:21:47AM +0400: > > On Sat, Oct 08, 2011 at 12:12:01AM +0200, Kristaps Dzonsons wrote: > > > On 07/10/2011 23:14, Yuri Pankov wrote: >=20 > >>> I want to propose the following change to man_validate.c - if we are > >>> missing SOURCE and VOL in TH, do the same as for the mdoc manpages - > >>> use OSNAME, if it's not defined, use uname output and get the VOL from > >>> msec.in if VOL isn't defined in manpage. I've attached the diff that > >>> seems to work for me (mostly just copy/paste from mdoc_validate.c), h= ope > >>> the idea sounds ok.. >=20 > I like your idea in general; it provides additional useful information > and makes mdoc(7) and man(7) formatting more similar, both of which > is good. >=20 > Before commit to bsd.lv and openbsd.org, you patch would require > minor tweaking (missing BUFSIZ definition, move function to the > right file, ...) but we could take care of those points. >=20 > >> I don't see groff doing this on any machines I have handy... do you ha= ve=20 > >> a use-case in mind for this behaviour? >=20 > Well, most of the man(7) manuals in the OpenBSD tree profit from > this, look at cvs(1) and tic(1) for example. >=20 > > It depends on the contents of the macro file it's using - yes, by > > default it doesn't do this, but given, e.g., > > http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/troff/troff= =2Ed/tmac.d/an > > you will get the the output with "Illumos" and translated man section if > > they are omitted in the manpage.. > >=20 > > I don't think that it's something where groff compatibility is needed. >=20 > We *do* value compatibility very much and don't want to introduce > gratuitious output differences, even in such small matters, at least > not without very good reasons. I don't see this change as introducing any incompatibility with groff output, that's more like default groff macro used - I'm not going to submit a request to change behaviour to groff lists, and if you see it as not appropriate, please just drop it. :-) > So i suggest that you contact the groff crowd and offer them a port > of your related an.tmac patch for their repository. Feel free to > mention that i'm in favour of making mandoc(1) follow their lead if > they take the patch - or, Kristaps, if you disagree, just say so. >=20 > I'm reading the groff lists and will see the commit to the groff > codebase. Thanks, Yuri --Pd0ReVV5GZGQvF3a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAABAgAGBQJOklrvAAoJEF9SuVmZPGsqKoQQALIcA8aKN63dOJ1zeSJOJYjS aCfPbI2BxpADNaZWnfwM8z2vjxCboHDNaSFYcB5uYQY7NgGDoqyIXXwdYYbTTRjf 7VQ4396LUjAXSQvNHJAaUU4SEyEQ5G2b9D3sYMLaXu1eyKFrdegvL6sdnpgl1XqQ j2GUsWfMa2z2iohR74AFJ2Nfs1Fz5mYyRXKZUFLubaoJbmq7AF6hNYbdBG76AiME PsWKp+QM9bWfUz4Ysn17xN9+gJX4xm9HLyzdeAAmUHMJtrzHwhcbeF5yZ77a39dl PnLLonXTRRYZTkfTW+Ch1fI+tC++MHi5tn9WJjr3wyuej73Cfy2ZjFeadGEhL8vd efb/4BDlrqg/+SWeKwtZQrxNJxqxQQalCWk1Rgqt4FLJuAIFFCPz4E4VovCGVlKg 3HJ7cFExXCFc0JHYiLtJ4fbMo3L2tCgLuIWcWNtEsOlHSQJx/Z7nYfDA6MrLxJ5m PcAW4aRMPTjdBEMXMfTOkVd5tCXNfAaS7WVH7OZ5cQed7XTACtJnCBRcwdQwGes4 3tuERH395xr7itX65uoAtui5UFpFFho5c+x7k2l6TXzi1Xy4xp7FKWDBUgY3/iHh XvIdDYA0m+wk2oT788fc0Civhj9JJpqZER4lYoIhnoqF5uYg7mTIMLZAMmlkIHv/ mZiD8wUl/TH3zbQBc7/W =14mX -----END PGP SIGNATURE----- --Pd0ReVV5GZGQvF3a-- -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv