From: Yuri Pankov <yuri.pankov@gmail.com>
To: Ingo Schwarze <schwarze@usta.de>
Cc: discuss@mdocml.bsd.lv
Subject: Re: Use OSNAME/uname and msec.in for man(7) input
Date: Mon, 10 Oct 2011 06:39:44 +0400 [thread overview]
Message-ID: <20111010023944.GI1294@procyon.xvoid.org> (raw)
In-Reply-To: <20111009223332.GF10611@iris.usta.de>
[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]
On Mon, Oct 10, 2011 at 12:33:32AM +0200, Ingo Schwarze wrote:
> Hi Yuri,
>
> 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:
>
> >>> 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), hope
> >>> the idea sounds ok..
>
> 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.
>
> 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.
>
> >> I don't see groff doing this on any machines I have handy... do you have
> >> a use-case in mind for this behaviour?
>
> Well, most of the man(7) manuals in the OpenBSD tree profit from
> this, look at cvs(1) and tic(1) for example.
>
> > 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.d/tmac.d/an
> > you will get the the output with "Illumos" and translated man section if
> > they are omitted in the manpage..
> >
> > I don't think that it's something where groff compatibility is needed.
>
> 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.
>
> I'm reading the groff lists and will see the commit to the groff
> codebase.
Thanks,
Yuri
[-- Attachment #2: Type: application/pgp-signature, Size: 834 bytes --]
prev parent reply other threads:[~2011-10-10 2:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-07 21:14 Yuri Pankov
2011-10-07 22:12 ` Kristaps Dzonsons
2011-10-07 22:21 ` Yuri Pankov
2011-10-09 22:33 ` Ingo Schwarze
2011-10-10 2:39 ` Yuri Pankov [this message]
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 \
--in-reply-to=20111010023944.GI1294@procyon.xvoid.org \
--to=yuri.pankov@gmail.com \
--cc=discuss@mdocml.bsd.lv \
--cc=schwarze@usta.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).