amsmath overwrites \dots

[kberry]

amsmath overwrites the kernel definition of \dots, and the amsmath \dots outputs a thinspace after the dots (\ifgtest@ is true, but I can't discern what that test is testing). It happens in the \dotso@ macro. Example:

\documentclass{article}
\usepackage{amsmath}
\begin{document}
x$\dots$y\loggingall
\end{document}

(the x y is there to show the visible space in the output before the y)

Output from the log file:

.....\OML/cmm/m/it/10 :
.....\glue(\thinmuskip) 1.66663
.....\OML/cmm/m/it/10 :
.....\glue(\thinmuskip) 1.66663
.....\OML/cmm/m/it/10 :
....\glue 1.66663
....\mathoff

I suppose it is too great an incompatibility to change amsmath now. But even when amsmath is not loaded explicitly, since unicode-math loads amsmath, the extra thinspace is also present in that case:

\documentclass{article}
\pagestyle{empty}
\usepackage{unicode-math}
\begin{document}
x$\dots$y\loggingall
\end{document}

with log:

....\TU/latinmodern-math.otf(1)/m/n/10 glyph#119
....\glue 1.66681
....\mathoff

Whereas with just the kernel \dots definition (comment out the \usepackage), there is no pesky extra thinspace.

....\glue(\thinmuskip) 1.66663
.....\OML/cmm/m/it/10 :
....\mathoff

Since unicode-math is so commonly loaded with unicode engines, the different behavior from the kernel is confusing. The "random" extra thinspace appearing and disappearing after the \dots makes it quite difficult to get consistent spacing around ellipses. The kernel definition is nice and simple. I wish it was used.

Similarly, I note amsmath redefines , and \thinspace and \cdots and probably plenty more. I know why they are there, but all these redefinitions seem problematic for people trying to use the Unicode engines and expecting the standard definitions. Since so much work has gone into improving standard latex and providing unicode support, it seems a shame for the "historical" definitions from amsmath to overwrite them.

Maybe amsmath could acquire an option not to redefine standard latex macros, and unicode-math could pass it? then people not loading amsmath explicitly would get the kernel definitions.

Whether changes are made in the code, at least the overwriting situation should be documented. (If it is already, sorry.) --thanks, karl.

[FrankMittelbach]

This is documented in the amsmath documentation section 4.3 (perhaps not that clearly, but that is always to some extent a question of taste). Basic point is that amsmath extends the \dotscommand to typeset the appropriate type of dots depending on context ... and it says if that is not appropriate one should use the amsmath specific commands that say which dots to use.

I would claim that for any serious math amsmath is needed anyway, so in that sense that confusion is usually not there if you have math in your document and move f

longterm goal is that amsmath becomes the loaded standard for future documents in which case there will be only one definition for \dots.

[kberry]

Basic point is that amsmath extends the `\dots`command It doesn't just "extend" the command. It changes the behavior by inserting a thinspace that the kernel definition doesn't. so in that sense that confusion is usually not there if you have math in your document and move It is nearly automatic to use unicode-math with documents intended for Unicode engines even when they aren't especially math-heavy. longterm goal is that amsmath becomes the loaded standard for future documents Sounds good, in general. in which case there will be only one definition for `\dots`. Although that means that default $\dots$ typesetting will change. Plus/minus the thinspace. Oh well. Hence my suggested intermediate-between-kernel-and-amsmath proposal, but I guess it is premature/too weird. -k

[FrankMittelbach]

Basic point is that amsmath extends the \dotscommand It doesn't just "extend" the command. It changes the behavior by inserting a thinspace that the kernel definition doesn't.

what I meant is that it extends/changes the meaning of \dots and yes any changes means that there is a difference with and without. But this is the case since day one whenever amsmath is loaded. The only "new" thing is that amsmath is loaded when you do unicode-math, and as I said I think it should get loaded thoughout at some point in the future

so in that sense that confusion is usually not there if you have math in your document and move It is nearly automatic to use unicode-math with documents intended for Unicode engines even when they aren't especially math-heavy.

well, yes maybe maybe not.

longterm goal is that amsmath becomes the loaded standard for future documents Sounds good, in general. in which case there will be only one definition for \dots. Although that means that default $\dots$ typesetting will change.
Plus/minus the thinspace. Oh well. Hence my suggested intermediate-between-kernel-and-amsmath proposal, but I guess it is premature/too weird. -k

I can't really think why this would make things better. There is no point in my opinion to use amsmath with 2 different definitions of \dots, because that would then for the future remain there as alternative paths even if amsmath is loaded and used. So I think the situation is better with just one behavior of a document if amsmath is loaded even if that means that if it is implicitly loaded you have to deal with such differences. Documents that use \DocumentMetadata (in the future) should in my opinion by default have amsmath active and part of the kernel without a need to load it as well as several other things. In my opinion we shouldn't make the same mistake as was done with NFSS where we has NFSS with that or this option for no document you really new how things behaved (easily). I very much prefer a clean cut.

[kberry]

My idea of "make things better" = "preserve latex kernel definition of \dots".
But I cannot argue with your logic, either.

BTW, I notice that plain.tex's \dots inserts a thinspace after \ldots. Which seems likely to be where amsmath got the idea.

[car222222]

@kberry Thus is because, "for mathm", the space at the end is the only correct usage:
"plain.tex's \dots inserts a thinspace"
the original (and following) LaTeX got it wrong!

[car222222]

@kberry But you are using it for text.
Is it intended to be an ellipsis? Or something distinct from this?
Maybe your usage needs some new command that does not need mathmode?
Aside: it would be best if such a new command did not use "hidden mathmode" as we are trying to eliminate all of this from LaTeX.