> > > 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).
