Re: [Groff] \*[SN] question

[Tadziu Hoffmann]

> > > question: can someone explain to me what actually is going
> > > on? somehow something seems to go wrong with the `.als SN
> > > SN-DOT' or I unintentionally mask the correct definition
> > > of \*[SN] or whatever. I don't get it why the `.NH' calls
> > > work, but \*[SN] no longer contains the correct
> > > information if I insert the `.SH' option in the macro
> > > definition. why have I explicitely `.rm SN' first??
> > > 
> > > any ideas would be appreciated :-)


I think the groff info file provides the answer:

  Unlike many other programming languages, undefined
  identifiers are silently ignored or expanded to nothing.
  When `gtroff' finds an undefined identifier, it emits a
  warning, doing the following:

    * If the identifier is a string, macro, or diversion,
      `gtroff' defines it as empty.

The new s.tmac says:

  .if !dSN .als SN SN-DOT

Also, NH uses/defines SN, but SH does not.

So, here's what happens:

  1. You invoke SH.  No problem so far.
  2. You reference SN, *thereby defining it*.
  3. You invoke NH, which sees that SN is already defined
     and therefore *does not* alias it to SN-DOT.

Number 3 explains why ".rm SN" fixes the problem.
Also, had you called ".NHH n xxx" with n>0 first, everything
would have been okay.

Quickfix:

  1. Use SN-DOT or SN-NO-DOT (your preference) instead of SN
     in your macro between XS and XE.

or

  2. At the top of your document, do

      .ds SN-DOT
      .als SN SN-DOT

     (alternatively, use SN-NO-DOT instead of SN-DOT).