On Thu, Feb 15, 2007 at 04:16:06PM +0000, Keith MARSHALL wrote: > 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). OK, I understand your point. > > >> 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.
I, at least, would welcome this change. > > Regards, > Keith.
