unicode-math silently redefines commands

[u-fischer]

As came up here https://tex.stackexchange.com/q/545396/2388 unicode-math (re)defines a lot commands at begin document without any warning. I don't think that this a good situation as it affects a very large number of command names.

Minimal example demonstrating the issue

\documentclass{article}
\usepackage{unicode-math}
\newcommand\zcmp{zz-compose}
\newcommand\Question{Question}

\begin{document}
Ups: \zcmp? \Question? 
\end{document}

[wspr]

Yes, this has come up before and I promised to fix it but I can’t remember what my solution was going to be…

How does this sound? A package option, one of:

mathcommands=reserve mathcommands=provide mathcommands=overwrite

(naming suggestions welcome)

reserve: defines placeholders at package load to prevent other packages overwriting symbols, overwrites definitions at begin document

provide: does not define commands until at begin document, using \providecommand (would be new default)

overwrite: current behaviour (commands defined at begin document and overwrite existing defs)

Alternatively unicode-math could “reserve” all commands at package load and then there would only be two options, provide (with a different mechanism) and overwrite

An orthogonal but related feature would be to define customisable “math tables” so offending entries can be deleted/renamed.

[davidcarlisle]

I think I'd just go for unconditionally defining them all at package load (unless you have some real use cases where the delay really helps) I can see delaying avoids some error cases but if you think you are loading a package that defines something and avoiding an error by delaying the unicode-math definitions until after the package loaded seems like not clearly a good thing.

On a related issue it would be good if we could load the default unicode math table into the format (probably hidden in a definition) to speed up loading.

[wspr]

Okay, simple is better and it might bring to light some general issues. I am pretty worried that there are a LOT of clashing macros, but we’ll see I suppose…

Loading in the kernel is a good idea.

[u-fischer]

like @davidcarlisle I think you should simply define them. But you could also add an option, say exclude={zcmp,Question} and/or excluderange={1232-1400} and then make such excluded command available e.g. with some generic command e.g. \unimathsym{zcmp}.

And i guess there will be some clashes, but they only will show up if unicode-math overwrote a command and so are imho fine.

[wspr]

On the topic of loading speed, the unicode-math-table file is only read once then stored in a macro. It’s the processing of that file that takes so long… :( lots of code untangling and optimisation needed!

I’m not sure I’d have an exclude thing — partially because of processing speed considerations. My first thought it just to allow a new unicode-math-table to be specified so users can scrub out the entries they don’t like. Probably both options together would be best!

[davidcarlisle]

@wspr must admit it's been a while since I looked exactly what you were doing with the table, but could you push the processing to format time as well, or do you need to wait until you know what font set is in use?

[wspr]

@davidcarlisle Currently it's dynamic, but if shouldn't be for the simple case of loading a single maths font.

What I'd really like to do is revive my old "low tech" approach to unicode maths that uses XeTeX font mapping and LuaTeX/luaotfload font glyph substitution that can set up a sensible default for unicode-maths in Umath engines... then unicode-math can become a more "bells and whistles" approach but isn't mandatory for all unicode documents that want to load a maths font.