Re: [Groff] \*[SN] question

[Keith MARSHALL]

Joerg van den Hoff wrote, quoting Tadziu Hoffmann:
>>> another question: wouldn't it be wiser to emit a warning in
>>> s.tmac a la
>>> 
>>> "warning: register `SN' already defined. cannot use it for
>>> section number. use SN-(NO-)DOT directly or remove `SN'"
>>
>> Hmm, this is a matter of debate, but I would say "not necessarily":

Nope.  The answer here is a definite `no', for the following explains
pretty much how it's intended to be used; see groff_ms(7).

>> for example, assume you want section numbering according to
>> DIN 1421 (ISO 2145), i.e., without the trailing dot.
>> Then you could say (in principle - see note below)
>>
>>   .ds SN-NO-DOT
>>   .als SN SN-NO-DOT
>>
>> and you wouldn't want to be annoyed with a warning for
>> something you expressly requested.
>>
>> Note: The above doesn't (yet) work, because NH explicitly
>> uses SN-DOT in the header.  However, I see no reason it
>> couldn't use SN.  Werner?
>
> with regards to NH behaviour this sure would be better. did'nt know that
> there is a DIN/ISO regulation for that kind of thing, but anyway 
omitting
> the trailing dot probably is the nicer variant (but maybe not for level
> one sections?).

It was I who added the SN-DOT/SN-NO-DOT extensions for 1.19.2 ms, and,
IIRC, I documented their intended behaviour in groff_ms(7), and in the
groff info file.

FWIW, I too was unaware of the DIN/ISO standardisation relating to this.
I chose to explicitly use SN-DOT within the NH definition, simply to
preserve existing behaviour, while allowing the user to choose which
format should be exposed for SN, if he wished to refer to it in any
context *after* an NH call, e.g. in a section number reference, (where
I tend to prefer the SN-NO-DOT form).

It would be trivial to change NH itself, to use the preferred SN format
in the heading it emits.  I've no strong preference either way; it would
depend only on how strongly we wish to preserve the classical behaviour.
Tadziu's suggestion would provide enhanced flexibility: the classical
behaviour would remain the default, but the user would have the choice
of preferred style in *all* contexts, and could always access the
alternative by explicit reference to SN-DOT/SN-NO-DOT on demand.

Regards,
Keith.