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: Sun, 21 Aug 2022 07:58:49 -0400 (EDT)

Follow-up Comment #4, bug #62801 (project groff):

Hi Dave!

[comment #3 comment #3:]
> I'm not sure I follow; the document is pretty light on examples.  Unless you
mean that the document's source includes -me usages that are not mentioned in
the document's content -- in which case, those seem like shortcomings that
ought to be addressed.

I simply mean stuff like the second sentences in each of the following.


.$0 T B n             This hook macro, normally undefined, is called au‐
                      tomatically  by  .sh  and .uh after they call .$p,
                      and is passed the same arguments.  You can  define
                      it  to,  for instance, automatically put each sec‐
                      tion title into a table of contents using .(x  and
                      .)x.

.$n                   These  hook macros (where n is an integer 1–6) are
                      called by .$p just before  it  outputs  a  section
                      heading  of depth n.  They could be used to obtain
                      section depth‐dependent spacing.


If we had an "Advanced _me_ User's Guide" that covered these and the other
package features not covered by _meintro.me_, then the reference could be thus
pared down.  That's all I mean!

> > Yes; my practice is not to ChangeLog changes to comments or
> > indentation in source code unless they seem to be of outsized
> > importance.
> 
> Maybe I wasn't clear: my concern is not with the ChangeLog entry, but that
the indentation of the revised code is misleading about the code's actual
flow.  It implies that the first "if" controls the entire indented block under
it, whereas in fact the second "if" executes unconditionally.  That is, the
indentation structure makes it appear the code sequence is:

I understood you but I failed to spell out my reasoning--brain moved faster
than fingers.

I agree with your correction but wasn't going to fork off a new Savannah
ticket for it.  And if I don't do that, there's no need to add a ChangeLog
entry for it.

The commit is pending in my working copy.


commit f1010bc03526882275be83ca236e70f7533a811d
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sat Aug 20 07:23:06 2022 -0500

    tmac/e.tmac (2c): Fix misleading indentation.
    
    Thanks to Dave Kemper for the report.



    _______________________________________________________

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]