discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Yuri Pankov <yuri.pankov@gmail.com>
Cc: discuss@mdocml.bsd.lv
Subject: Re: Use OSNAME/uname and msec.in for man(7) input
Date: Mon, 10 Oct 2011 00:33:32 +0200	[thread overview]
Message-ID: <20111009223332.GF10611@iris.usta.de> (raw)
In-Reply-To: <20111007222147.GH1294@procyon.xvoid.org>

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.

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,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

  reply	other threads:[~2011-10-09 22:46 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 [this message]
2011-10-10  2:39       ` Yuri Pankov

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=20111009223332.GF10611@iris.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mdocml.bsd.lv \
    --cc=yuri.pankov@gmail.com \
    /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).