discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: discuss@mdocml.bsd.lv
Subject: Re: Opinions on .Dd?
Date: Sun, 25 Jul 2010 08:25:09 +0200	[thread overview]
Message-ID: <20100725062509.GA22919@iris.usta.de> (raw)
In-Reply-To: <4C4BBDE5.8020901@online.de>

Hi Sascha,

Sascha Wildner wrote on Sun, Jul 25, 2010 at 06:30:29AM +0200:

> what is people's thought on .Dd in general?

While there are some mdoc(7) features that are handled differently
by different operating system variants, .Dd so far is one of those
where there is consensus that it is required, and what it means.

I admit conventions differ slightly on how to format the date line:
While OpenBSD uses the Mdocdate mechanism to automatically insert
the date on commit, NetBSD and FreeBSD do not.

This difference is not a problem because mandoc and groff handle
both conventions.  Thus, you can format OpenBSD manuals on NetBSD
and FreeBSD and Linux and vice versa without using a special binary
or special options.

Thus, the situation with respect to .Dd is fine right now.

> Personally, I've thought about nuking it more than once.

Hm, frankly, i recommend against that.  That would break well-
established syntax, weakening portability of DragonFly manuals.
While it would certainly be possibly (though ugly!) to deal with
it in mandoc(1) in the future, you might also wish to consider
compatibility with operating systems that don't provide mandoc
at all.  Some are using groff, some are still using traditional
System V nroff/troff descendants, and you will hardly convince
all of those people to deal with changes of basic mdoc(7) syntax
introduced in DragonFly.  Breaking established syntax at this place
would be particularly bad because it would result in DragonFly
manuals no longer being recognized as mdoc(7) manuals at all...

For example, when i remove the .Dd line from an mdoc(7) manual
on Linux and explicitely call nroff -mdoc, it still works, but
with nroff -mandoc, it is no longer recognized and output is
completely clobbered.  Good luck convincing Werner Lemberg to spend
his time changing that, and after convincing him, be prepared to
wait some years for all distributions to pick it up...  :-/

> Most developers forget to update it and honestly both running after
> people and reminding them as well as keeping them up to date myself
> are a pain.

Right, i understand the problem, and certainly such issues are the
worse the smaller a project is in terms of the number of active
developers.  Developer time is often a scarce resource, both for
hacking and for communication.

Maybe porting Mdocdate to DragonFly cvs might help you:  I think
is solves exactly the problem you describe.  I just checked on
Linux, non-OpenBSD groff auto-detects pages containing Mdocdate
as mdoc(7) and formats them nicely.  I'm sorry i don't have a
Solaris box and can't check there...

> Also, at least in DragonFly, I see no real benefit in keeping it up
> to date, since nobody goes and checks the date on manpages to decide
> which are worth looking through for new stuff.

I admit the usefulness of the date in the footer is marginal:
In particular, it doesn't mean that the page was completely
accurate at that date.  Maybe somebody only fixed a typo on that
date.  The main advantage seems to be that you can figure out
the version in case people mail manuals around, which indeed
doesn't happen that often.

> We also don't have translations of manpages

*shudder*

[...]
> This was the reason given to me when I asked about .Dd
> on the FreeBSD lists once.

I have a hard time buying that it would be needed or even helpful
for that purpose.  I mean, when the last checkin in the master repo
is more recent than the last checkin in the translation repo, you
need to check the translation, right?  The .Dd macro, on the other
hand, is not reliable; what if the developer updating the manual
forgot about the .Dd line?  What if there were several checkins
on the same day?

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

  reply	other threads:[~2010-07-25  6:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-25  4:30 Sascha Wildner
2010-07-25  6:25 ` Ingo Schwarze [this message]
2010-07-25 12:08   ` Sascha Wildner
2010-07-26 13:42     ` Kristaps Dzonsons
2010-07-26 14:50       ` Jason McIntyre
2010-07-26 14:56         ` Kristaps Dzonsons
2010-07-26 15:06           ` Jason McIntyre
2010-07-25  8:37 ` Jason McIntyre

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=20100725062509.GA22919@iris.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mdocml.bsd.lv \
    /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).