Katex: Support for \mod, \bmod, \pmod, and \pod

[jschaf]

Got a parse error using \bmod.

ParseError: KaTeX parse error: Expected 'EOF', got '\bmod' at position 7: k \bmod̲ 3

Here's some detail on the different modulus operators in LaTeX. http://www.matthewflickinger.com/blog/archives/2005/02/20/latex_mod_spacing.asp

[kevinbarabash]

It shouldn't be too hard to implement these. I'm guessing \mod and \bmod are more commonly used.

[maryfries]

:+1:

[chmln]

Hate to +1, but lack of modulus is a significant drawback

[gagern]

These macros are defined in amsmath.sty as follows:

\renewcommand{\bmod}{\nonscript\mskip-\medmuskip\mkern5mu\mathbin
  {\operator@font mod}\penalty900
  \mkern5mu\nonscript\mskip-\medmuskip}
\newcommand{\pod}[1]{\allowbreak
  \if@display\mkern18mu\else\mkern8mu\fi(#1)}
\renewcommand{\pmod}[1]{\pod{{\operator@font mod}\mkern6mu#1}}
\newcommand{\mod}[1]{\allowbreak\if@display\mkern18mu
  \else\mkern12mu\fi{\operator@font mod}\,\,#1}

So a \bmod always has 5/18em before and after the operator name, without the extra 4/18em you'd usually get from a binary operation in non-script style. I guess that if the \bmod gets turned into an atom other than Bin, the negative skip might actually reduce the surrounding space. The \penalty is irrelevant as we don't wrap, as is the \allowbreak. A \pod has 1em leading space in display style, or 8/18em otherwise. A \mod has 1em resp. 12/18 em before and 6/18em after.

I guess we could turn all those offsets into \kern or the corresponding internal representation.

[kevinbarabash]

It would be nice if we could parse mu units and support mkern and all of the muskips. If we hardcode values for these it means more work later if we want to support redefining medmuskip etc.

[gagern]

I think it would be fairly easy to (a) support mu as simply another length unit and (b) treat \mkern as an alias to \kern and so on. That means people could write KaTeX code which LaTeX would reject due to use of wrong units. But I think that everything that LaTeX supports should work using this approach as well.

[edemaine]

This can be closed now, thanks to #582, right?