coloneq

[davidcarlisle]

Issue https://github.com/wspr/unicode-math/issues/590 points out that mathtools defines coloneq differently to unicode-math.

mathools defines coloneq and Coloneq to be (constructed) characters :- and and ::- and uses coloneqq and Coloneqq for ≔and ⩴ It documents these names documented as coming from txfonts.

the :-forms appear to be in error. They are not in Unicode (or amsfonts) and the newtxmath package that updates txfonts documents

\coloneq and \eqcolon now point to the correct glyphs;

so there coloneq and coloneqq are the same, := (but Coloneq still uses a ::- character).

I think mathtools should match unicode-math here and use := having the qq names as legacy aliases, probably with an option to keep the current behaviour. But I will contact newtxmath author

[daleif]

Hmm, apparently I forgot to save my comment from friday.

I think it would be an idea to define these symbols as \MT<somename> macros, and then map the "official" names to these. Then the \MT... names will always be available no matter what. And we can define macros as say \MTcolondash, \MTcoloncolondash more descriptive to what they actually show.

[daleif]

That is I'm defining these

\newcommand*\MTdblcolon{\vcentcolon\mathrel{\mkern-.9mu}\vcentcolon}
\newcommand*\MTcoloneq{\vcentcolon\mathrel{\mkern-1.2mu}=}
\newcommand*\MTdblcoloneq{\dblcolon\mathrel{\mkern-1.2mu}=}
\newcommand*\MTcolondash{\vcentcolon\mathrel{\mkern-1.2mu}\mathrel{-}}
\newcommand*\MTdblcolondash{\dblcolon\mathrel{\mkern-1.2mu}\mathrel{-}}
\newcommand*\MTeqcolon{=\mathrel{\mkern-1.2mu}\vcentcolon}
\newcommand*\MTeqdblcolon{=\mathrel{\mkern-1.2mu}\dblcolon}
\newcommand*\MTdashcolon{\mathrel{-}\mathrel{\mkern-1.2mu}\vcentcolon}
\newcommand*\MTdashdblcolon{\mathrel{-}\mathrel{\mkern-1.2mu}\dblcolon}
\newcommand*\MTcolonapprox{\vcentcolon\mathrel{\mkern-1.2mu}\approx}
\newcommand*\MTdblcolonapprox{\dblcolon\mathrel{\mkern-1.2mu}\approx}
\newcommand*\MTapproxcolon{\approx\mathrel{\mkern-1.2mu}\vcentcolon}
\newcommand*\MTapproxdblcolon{\approx\mathrel{\mkern-1.2mu}\dblcolon}
\newcommand*\MTcolonsim{\vcentcolon\mathrel{\mkern-1.2mu}\sim}
\newcommand*\MTdblcolonsim{\dblcolon\mathrel{\mkern-1.2mu}\sim}
\newcommand*\MTsimcolon{\sim\mathrel{\mkern-1.2mu}\vcentcolon}
\newcommand*\MTsimdblcolon{\sim\mathrel{\mkern-1.2mu}\dblcolon}

for completeness I've also added the reverse of the approx and sim symbols. I'll then map the current and legacy option macros on to these. Additionally I'll add

    \providecommand*\approxcolon{\MTapproxcolon}
    \providecommand*\approxColon{\MTapproxdblcolon}
    \providecommand*\simcolon{\MTsimcolon}
    \providecommand*\simColon{\MTsimdblcolon}
    \providecommand*\colondash{\MTcolondash}
    \providecommand*\Colondash{\MTdblcolondash}
    \providecommand*\dashcolon{\MTdashcolon}
    \providecommand*\dasColonh{\MTdashdblcolon}

to both sets (need to see if otherse define these as well)

BTW: do we need to define these as robust? Is that the trend noadays?

[davidcarlisle]

I'm not sure I like the \MT... names, the main motivation for having the commands at all is to try to unify the names between unicode-math and 8-bit font packages like newtxmath that provide the symbols. It's already anomalous that mathtools is defining character commands at all, it is mostly an extension of amsmath not amssymb Adding document accsesible package specific names seems to be going in the wrong direction.

[daleif]

We can just add a @ and not expain them. I'd rather give users opportunities instead of limiting them as to what they can do. For example why no add \simcolon no-one else is? Just because a symbol is not in unicode does not mean some strange mathematician somewhere isn't using it.

Regarding amsmath vs amssymb: I think mathtools have had extra symbols from ay one.

[davidcarlisle]

yes I agree mathtools has always added these, but longer term it would be good to get some agreed list of names including, as you say, some non-unicode names, then make sure they are available for all font packages. Pragmatically speaking adding them here rather than getting agreement to add to the various font packages probably makes sense, although font packages better in the end as they know if the character is natively in the font. You have \providecommand so that is all good, but yes \MT@... names for the fallback definitions would be better I think so they do not end up being used in documents.

[daleif]

That is also what I just changed them to (\MT@...)

Since we are more or less removing support for :- (by renaming) I'm still adding the extra 8 symbols just for completeness.

[davidcarlisle]

thanks, looks fine now

[schlcht]

just as a cautionary advice: microtype uses \MT@ as its internal prefix.

[FrankMittelbach]

just as a cautionary advice: microtype uses \MT@ as its internal prefix.

and probably was first, good point, might be best to avoid potential conflicts in the future. Why not go for mathtools@ or mtools@ instead?

[daleif]

Isn't mathtools older than microtype? It was started in 2002, microtype is from 2004.

[FrankMittelbach]

@daleif what I meant is that mathtools didn't use MT@ as a prefix, it was all pre-expl3 names with underscores MT_ if I remember correctly. But whoever claims first son, the point is that if both packages are using the same prefix then this can lead to confusion.

[daleif]

It has always been using both \MT@ and \MT_

[daleif]

A new version have been sent to CTAN. I did rename the new internal versions to use \MATHT@ as a prefix