Fix \hphantom width

[ronkok]

Fixes #1805. I also applied the same fix to \smash, since it had the same problem.

[codecov-io]

Codecov Report

Merging #1809 into master will decrease coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1809      +/-   ##
==========================================
- Coverage   94.58%   94.56%   -0.03%     
==========================================
  Files          80       80              
  Lines        4655     4656       +1     
  Branches      809      809              
==========================================
  Hits         4403     4403              
- Misses        227      228       +1     
  Partials       25       25

Flag	Coverage Δ
#screenshotter	88.81% <100%> (-0.02%)	⬇️
#test	86.61% <100%> (ø)	⬆️

Impacted Files	Coverage Δ
src/functions/phantom.js	100% <100%> (ø)	⬆️
src/functions/smash.js	87.8% <100%> (+0.3%)	⬆️
src/buildCommon.js	98.08% <0%> (-0.39%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8346294...7e64e6d. Read the comment docs.

[ronkok]

Okay, screenshot tests are in. This should be good to go.

[ylemkimon]

Does this apply to only bin and rel or other atom types?

[ronkok]

I don't think we need to consider mathopen or mathclose since an unmatched instance of either would cause a parse error. But your question does apply to mathpunct. It gets slightly different spacing treatment than a mord.

I'll modify the PR, but it might be a few days before I get to it.

[ylemkimon]

In that case, you could use a fragment or a partial group (#1706).

[ronkok]

@ylemkimon's question prompted me to do a little more research. I find that I was wrong about how \phantom and \hphantom behave in TeX and LaTeX. I thought that they would get the same horizontal spacing as the kind of atom that they contain, but that turns out to be incorrect. They actually get the same spacing as a mord, no matter what their argument is.

A year ago, I would have suggested that we should apply binrel spacing and ship something better than TeX. But suggestions of that sort don't seem to make their way into KaTeX master. Instead, I'll modify the code in this PR and I'll also modify \phantom so that they emulate TeX behavior.

[kevinbarabash]

@ronkok now that we have to strict mode we can ship TeX's behavior behind that flag and a better behavior by default.

[edemaine]

@ronkok Instead of parser.settings.strict !== false you should use parser.settings.useStrictBehavior(). See Settings.js.

[ronkok]

you should use parser.settings.useStrictBehavior()

I decline to fight the flow battle that would ensue from that choice. Feel free to push a commit if you feel strongly about it.

[edemaine]

@ronkok Done. Sorry for the confusion about whether useStrictBehavior() needs arguments (it does). I do feel strongly about this, as strict can be a function or string, not just a boolean.

Unfortunately, I had to add nonstrictSettings to a lot of tests to avoid them causing warnings. It'd be nice if we could just generate the warning (when strict is warn) when it would actually make a difference (i.e. when binrelClass(...) !== 'mord') but I unfortunately didn't see an easy way to do that (because useStrictBehavior gets called in the handler, while binrelClass gets called in the htmlBuilder).

[ronkok]

I can imagine people who want an exact emulation of LaTeX. I can imagine people who want a more permissive, MathJax compatible library. I cannot imagine someone who wants exact emulation in every detail except the width of \hphantom.

We have made KaTeX options too complex. In particular, we have made the strict setting far too complex. There is negligible benefit to its multiple permutations and commit 43bcfad should be discarded.

[ronkok]

If we keep 43bcfad, let's at least write docs without an error. In TeX, \hphantom does not result in op spacing. It applies \mathpalette, which expands to a math group, which get the same spacing as an ord atom.

Also, I wrote this PR to alter \hphantom and \smash, not \phantom. I prefer not to degrade the behavior of our current \phantom just to follow a bad TeX example. Such a course would damage the rendering of an example like this.

[edemaine]

@ronkok I was mainly concerned about issuing warnings when strict === 'warn', consistent with the other strict/nonstrict behaviors listed on https://katex.org/docs/options.html

Your point about strict being complicated is warranted, though perhaps a discussion for another issue. The argument at the time was "most people should use true/"error", "warn", or false, and let's add a generic callback for anyone who wants to do something special". Indeed, I could imagine someone wanting to add nonstrict behavior for e.g. newlines, but otherwise be LaTeX compatible...

I'm personally a little worried about adding nonstandard behavior for \hphantom that is not reproduced by any other LaTeX engine. (I just checked, and MathJax has the mord behavior just like LaTeX.) Do we want to add another incompatibility between different LaTeX engines? I'd rather add a generic binrel tool if we could... But if we do add incompatibility, I think we should do it in the way that all other strict-based incompatibilities are done.

[ronkok]

I don't like the additional strict setting, If the only way I can get rid of it is to discard bin|rel for \hphantom and \smash, then let us discard bin|rel.

[ronkok]

The latest commit removes the bin|rel functionality. \hphantom and \smash now return a mord at all times. KaTeX will apply spacing in a way that matches TeX behavior.

I don't imagine that people often put a bin atom or a rel atom into \hphantom. It's only an edge case. But I have now intentionally made that edge case behave badly, in order to prevent something even more foolish in the docs. This smells.

[edemaine]

I'm personally a fan of this, and LaTeX compatibility in general, as it means you can take math from a webpage and put it directly in a LaTeX document.

One can always wrap in \mathrel to fix... :-/