On Fri, Mar 20, 2020 at 04:53:19PM +0100, Ingo Schwarze wrote: > Not really. In the POSIX sense, options are indeed options while > primaries are arguments. That has implications, for example that > all options must precede all primaries. Fair point.
> I don't feel very strongly about that, but i think .Cm does make > slightly more sense for primaries than .Fl (and .Ic is probably > acceptable, too, even though .Cm might be better because these are > command line arguments, not stand-alone commands). It does, however because the resulting effect is usually the same, I see no problem in using `Fl' for primaries. > I think that is reasonable, yes. I think it makes sense to consider > tags as words, i.e. strings that usually consist of letters and may > sometimes contain digits, but never contain whitespace and usually > do not start with punctuation characters. I'm not sure this rule of > thumb can be made very strict, but i think it is possible to polish > this by handling a small number of common cases. For example, > automatic tagging in man(7) already discards leading whitespace, > some escape sequences, and leading dashes from tags. Automatic > tagging in mdoc(7) already discards leading zero-width spaces > and leading backslashes. I think it would make sense to also > skip leading dashes here, see the patch below. > > Do you agree with that? Yes, I very much do. Given the fact man(7) already works that way, I'm happy to see mdoc(7) follow; it seems like the right approach, my attempt seems more of a workaround for special cases like find(1). OK kn
