[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

mm(7) DT string and super/subscripts (was: troff Memorandum Macros docum

From: G. Branden Robinson
Subject: mm(7) DT string and super/subscripts (was: troff Memorandum Macros documentation derived from the paper "MM - Memorandum Macros")
Date: Mon, 9 Aug 2021 22:11:57 +1000
User-agent: NeoMutt/20180716

Hi, Nate!

At 2021-08-09T03:12:42-0500, Nate Bargmann wrote:
> What I have been able to ascertain is that MM was an evolution and
> extension of MS by Bell Labs as both originated there.  Also, I think
> that either MS or MM is relatively easy to learn for anyone versed in
> MAN, though there are differences, of course.

I agree with the foregoing.  mm seems to have absorbed a lot of lessons
about macro package design from ms and man(7)--not a surprise given that
ms blazed a trail in this field.

> If there is a nit to pick, it is that groff_mm.7 may still be
> incomplete.  The book above provides the following string macro for
> printing the current date:
>       Today is \*(DT.
> I find 'DT' referenced in the description of the ISODATE macro and
> nowhere else in the page (groff 1.22.4; the string is completely
> removed in the Git HEAD of contrib/mm/, yet it works
> just fine.
> IMO it should be included in the "strings used in mm" subsection.  Is
> there a reason why it is not and why its mention has been removed
> completely rather than expanded?

I took it out as part of commit 4f3b1e33[1], 13 July (just a few weeks
ago).  I was revising the material that had to do with the `ISODATE`
macro and `Iso` register, both of which are groff extensions, and I
found them inadequately documented for my taste.  I further noticed
that the `DT` string was nowhere used _within_ the macro package proper,
but only in the extensions that implemented some cover sheet styles,
which, judging by some bugs I'd found in them, I regarded as

I didn't realize the `DT` was a traditionally exposed string--it's
thanks to this thread that some real mm documentation has come my way.
I haven't been treating O'Reilly and Dougherty's _UTP_ as comprehensive
or authoritative, because with ms I know they encourage the reader to
get under the hood and muck around with package internals.

It looks like I will need to restore documentation of the string, so
I'll do that.

> One drawback to MM is the lack of native super/subscript macros.
> However, I lifted the superscript formulas from s.tmac and include
> their definitions at the top of my letterhead file, appropriately
> named SUP/SUPX as borrowed from MOM.  ;-)

It would be straightforward to bring over the super- and subscripting
macros from groff ms; this would give us string names that "port" across
all of groff ms, mm, and me(7), which seems like an ergonomically kind
thing to do.

Here are the definitions from groff ms[2][3].

        .\" superscript
        .ds par@sup-start \v'-.9m\s'\En[.s]*7u/10u'+.7m'
        .als { par@sup-start
        .ds par@sup-end \v'-.7m\s0+.9m'
        .als } par@sup-end
        .\" subscript
        .ds par@sub-start \v'+.3m\s'\En[.s]*7u/10u'-.1m'
        .als < par@sub-start
        .ds par@sub-end \v'+.1m\s0-.3m'
        .als > par@sub-end

The internal string names would not necessarily be the same for mm,
though they might be: groff mm is architecturally quite similar to
groff ms in this respect.

It's certainly easy to do.

What do you think?


[3] The ones from me(7)[4] are worth a look, too.

        .\" GNU pic sets this register to 1 to indicate that \x should
        .\" not be used.
        .@R 0x
        .ds { \v'-0.4m'\x'\\n(0x=0*-0.2m'\s-3
        .ds } \s+3\v'0.4m'
        .\" for compatibility with traditional -me
        .\" (the first will work only in compatibility mode)
        .ds [ \*{
        .ds ] \*}
        .ds < \v'0.4m'\x'\\n(0x=0*0.2m'\s-3
        .ds > \s+3\v'-0.4m'
        .ds - \(em

I did a double-take at those string defs at first.  One seldom sees
Boolean operators embedded in arithmetic expressions these days, but it
was once a more common idiom, when every language's expression parser
would helpfully do the equivalent of performing a reinterpret_cast<> on
every rvalue for you.  The good old days, when a hackers ate gravel,
drank whiskey for breakfast, and left data types in the ivory tower
where they belonged!


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]