discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
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 --]

      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).