discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: "Anthony J. Bentley" <anthony@anjbe.name>, Jan Stary <hans@stare.cz>
Cc: discuss@mandoc.bsd.lv
Subject: hyphen-minus, was: docbook2mdoc-1.0.0 released
Date: Sun, 21 Apr 2019 14:32:57 +0200	[thread overview]
Message-ID: <20190421123257.GA31325@athene.usta.de> (raw)
In-Reply-To: <74092.1555800985@desktop.ajb.soy>

Hi Jan & Anthony,

Anthony J. Bentley wrote on Sat, Apr 20, 2019 at 04:56:25PM -0600:
> Jan Stary writes:

>> BTW, is "Fl -option" the preferred way to handle --long-options?

Yes.

> I've seen "Fl -option" and "Fl Fl option" about equally.
> Personally I prefer Fl Fl,

We did that for some time, but generally stopped doing so because
even though the printed output looks correct, it is logically
misleading.  There is only a single option here, not two, and .Fl
without an argument means the special option "-", as it occurs for
example in lprm(1) and tset(1).

  http://mandoc.bsd.lv/mdoc/style/options.html

    (note that already recommends .Fl -option even though it was
     last updated more than two years ago)

> because in some groff outputs "Fl -option" prints
> the first and second - as visibly different characters.

Oh wow.  All the discussion we recently had about whether to
recommend "\-" or "-" as input for desired HYPHEN-MINUS output
was based on the assumption that groff contained, for the man(7)
and mdoc(7) macros, a mapping of '-' to \N'45'.  It does indeed
for UTF-8.  But for PostScript and HTML, '-' actually comes out
as a hyphen from groff, even for manual pages...

How could we possibly miss that after years of delimberation?
I'm so tired of this matter...

> Fl Fl also means that mandoc's tagging support lets me search
> for "option" instead of "-option", and that feels more natural to me.

That works either way:

   $ grep version `man -w openrsync`              
  .Op Fl -version
  .It Fl -version
  Print version and exit.
  protocol version is older than the local protocol version.
  is compatible with rsync protocol version 27
   $ man -k Fl=version | grep rsync               
  openrsync(1) - synchronise local and remote files
   $ man -k Fl~version | grep rsync 
  openrsync(1) - synchronise local and remote files

You would have to go out of your way to not make it work:

   $ man -k Fl~^version | grep rsync
   $ 

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

  reply	other threads:[~2019-04-21 12:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-17 19:24 Ingo Schwarze
2019-04-20 19:03 ` Jan Stary
2019-04-20 22:56   ` Anthony J. Bentley
2019-04-21 12:32     ` Ingo Schwarze [this message]
2019-04-21 16:32       ` hyphen-minus, was: " Anthony J. Bentley
2019-04-21 11:26   ` Stephen Gregoratto
2019-04-25 17:02     ` Ingo Schwarze
2019-04-21 15:29   ` Ingo Schwarze

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=20190421123257.GA31325@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=anthony@anjbe.name \
    --cc=discuss@mandoc.bsd.lv \
    --cc=hans@stare.cz \
    /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).