discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: "Anthony J. Bentley" <anthony@anjbe.name>
To: discuss@mandoc.bsd.lv
Subject: Fl Fl for long options
Date: Sun, 26 Apr 2020 16:59:03 -0600	[thread overview]
Message-ID: <14105-1587941943.721637@wO-a.W87w.5Fm4> (raw)
In-Reply-To: <8a57c2f3270c2455@mandoc.bsd.lv>

Hi Ingo,

schwarze@mandoc.bsd.lv writes:
> Log Message:
> -----------
> While we do not recommend the idiom ".Fl Fl long" for long options
> because it is an abuse of semantic macros for device-specific
> presentational effects

Since we've had this discussion before, I feel like I must reiterate my
disagreement here. "Fl Fl" is a perfectly natural way to represent long
options and it's how I've always done it.

And again, I still find it incredibly unintuitive that in OpenBSD's
grep(1) manual jumping to the --label tag unintuitively requires
searching for "-label" rather than "label".

Interpreting "Fl Fl foo" as "empty flag followed by flag foo" simply
doesn't make sense to me. I'm aware there are cases like lprm(1) and
tset(1) that have an empty flag. Even if those were typical examples--
and they are decidedly not--where in those pages would it ever make
sense to use that empty flag adjacent to another? Is there a single
manpage anywhere that ever uses "Fl Fl" to mean something *other* than
long options?

Maybe I just don't understand how this works. But considering the
prevalence of Fl Fl as long option, clearly I'm not alone.

-- 
Anthony J. Bentley
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv


       reply	other threads:[~2020-04-26 22:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8a57c2f3270c2455@mandoc.bsd.lv>
2020-04-26 22:59 ` Anthony J. Bentley [this message]
2020-04-27  0:16   ` Ingo Schwarze
2020-04-27 10:02     ` Anthony J. Bentley

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=14105-1587941943.721637@wO-a.W87w.5Fm4 \
    --to=anthony@anjbe.name \
    --cc=discuss@mandoc.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).