bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #62801] [me] doc/meref.me.in: Clarify a couple points about empty m


From: G. Branden Robinson
Subject: [bug #62801] [me] doc/meref.me.in: Clarify a couple points about empty macro arguments
Date: Sat, 20 Aug 2022 07:52:52 -0400 (EDT)

Update of bug #62801 (project groff):

                  Status:                    None => Confirmed              

    _______________________________________________________

Follow-up Comment #2:

[comment #0 original submission:]
> A few -me macros (.ip, .sh, .$p, .2c since commit 01cf10eb
<http://git.savannah.gnu.org/cgit/groff.git/commit/?id=01cf10eb>, probably
others) accept empty arguments, but the _me Reference Manual_ doesn't say how
to pass an empty argument to a roff macro.  The full troff manual does, or
probably most users can figure it out with a couple of guesses, but the -me
manual may as well have a sentence in the introductory material to spell it
out, since the macro set does make use of the capability.

This bit I don't agree with; this document (the "_me_ Reference Manual")
explicitly expects the reader to possess a significant command of the _troff_
language.  I'm sticking on this point because space is at a premium on page 1
of this document in (electronic) dead tree form.

For what it's worth, several _me_ features in this document present examples
of usage, which I would also happily chop out except for the fact that they
are not elsewhere introduced.  I would like for this reference to be even
tighter than it is, but not at the cost of mystification.

> In the wake of the aforementioned commit, it may also be worth having the
.2c description explicitly say that this macro can accept an empty first
argument.  Bug #61671, which precipitated this commit, notes that the manual
didn't forbid it before, prompting the change, but it still doesn't expressly
endorse it either, which it perhaps should now that it's specifically
supported.

I agree.

> (That bug's comment 2--made after the bug was already closed, giving it low
visibility--also notes a minor indentation issue in the commit.  This is not
strictly related to the documentation issue noted above, but as an adjacent
issue that's not really worth opening up a new bug report for, I note it
here.)

Yes; my practice is not to ChangeLog changes to comments or indentation in
source code unless they seem to be of outsized importance.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62801>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]