Katex: globalGroup adversely affects \color and tall right delimiters

Created on 13 Nov 2020 · 14Comments · Source: KaTeX/KaTeX

PR #2091 has an unintended consequence. When the rendering option globalGroup is set to true, then \color escapes its group and affects tall right delimiters.

The KaTeX function\color works by creating a macro \current@color and assigning a color to it. When globalGroup is true, then this macro escapes its group. Tall right delimiters are then given that color in line https://github.com/KaTeX/KaTeX/blob/21c4bc355c04cfa13bb79dd9dd06627f5b04f54d/src/functions/delimsizing.js#L155. I don't know why tall right delimiters get that treatment, but there it is.

The stated reason for PR #2091 was to give global scope to \newcommand. But its effect is more sweeping than that. I think that @edemaine's comment was correct. We need some mechanism that gives global scope to \newcommand, not to all macros.

bug

Source

ronkok

All 14 comments

I wonder if there is a way to instead just prevent the color escaping side effect.

But yes, if it is hard, then I suppose it does not matter much as users can use gdef instead of def, and those are less important that newcommand anyawys.

I would keep the option name unchanged I think in any case, as it is more descriptive/specific than strict. E.g. in normal LaTeX, putting those definitions in global scope would make them visible to other $$ equations, so it is not strictly strict (i.e a LaTeX extension) in that sense, but rather a way of saying "this goes in global scope". \def not being global could be considered a known incompatibility instead.

cirosantilli on 14 Nov 2020

Could you give an example?

ylemkimon on 14 Nov 2020

I'm surprised that this happens. While the original #2091 made all defs global, which would be very bad (it would also mess with array's temporary redefinition of \\), the #2091 that got merged only makes the top-level group that math gets evaluated in the global group. I don't think this should affect how \current@color works, but I might be missing something. Perhaps #1845 in general?

edemaine on 15 Nov 2020

@ylemkimon For an example, I've created a minimal HTML document. It's entire <body> is:

<p data-tex="\color{#0000FF} AaBb123"></p>
<p data-tex="\left.\frac a b \right)"></p>
<script>
  const ps = document.getElementsByTagName("p")
  const macros = {};
  [...ps].forEach(el => {
    const tex = el.dataset.tex
    katex.render(tex, el, {globalGroup: true, macros})
  });
</script>

The resulting rendering is:
color

ronkok on 15 Nov 2020

@cirosantilli Yes, globalGroup is more descriptive and specific than strict, but KaTeX now has fourteen different options. It's enough that some users, smart users, describe their reaction as "my eyes glaze over".

Since strict was created to enable a toggle between LaTeX behavior and MathJax behavior, it seems to me that this feature falls into that category. As such, I wish to avoid creating unnecessary options.

That said, I don't have strong feelings about the option name. If everyone else wants globalGroup, I can accept that.

ronkok on 15 Nov 2020

I'll mention one other thing. I think it is valuable to maintain a distinction between \def and \gdef regardless of what happens to right delimiters. \def should not be global.

ronkok on 15 Nov 2020

👍1

Ah, that example makes sense. I was thinking you meant a single math expression, but certainly there could be leakage between the two - that's sort of what the globalScope option means... Note that this will only be an issue for \color at the top level.

I think the fundamental issue here is that globalScope is simulating preamble mode, but we're writing math in it, which is normally protected by a scope. I feel like globalScope has its use, but I certainly wouldn't recommend it for general math expression use.

For color specifically: We could clear \current@color at the end or beginning of a KaTeX execution... But I'm not sure whether that's ideal either. Another fix would be to not set \current@color if we're at the top level, as it's just meant to fix surrounding \rights. This would fix all the cases I can think of...

edemaine on 15 Nov 2020

Note that this will only be an issue for \color at the top level.

It will actually be an issue for any top level \def, not just color. You probably already realize that, but I want it clearly stated.

Please cast an eye over PR #2640. It's intent is to restore local scope to any \def, regardless of KaTeX settings. \newcommand can still persist between calls to KaTeX, which accomplishes the original goal for globalScope.

ronkok on 15 Nov 2020

👍1

Sorry, yes, I meant that it wouldn't affect \color that is nested within a group.

To me, it's confusing to make \newcommand and \def behave differently, because they behave the same in LaTeX...

What about defining \gnewcommand or some similar name, like \gdef but in \newcommand syntax? That at least could be implemented in LaTeX.

edemaine on 15 Nov 2020

For color specifically: We could clear \current@color at the end or beginning of a KaTeX execution... But I'm not sure whether that's ideal either.

\current@color was added in #1845 in order to fix #1844. I think we can clear \current@color at the end even if globalGroup is true.

ylemkimon on 16 Nov 2020

To me, it's confusing to make \newcommand and \def behave differently, because they behave the same in LaTeX...

We already have a mode in which KaTeX macros act like LaTeX. It's strict mode, globalGroup = false. The whole point of globalGroup was to create something that behaved differently than LaTeX. And the motivation behind that difference was to get a global \newcommand. If we want to preserve any local top-level macros, then \def and \newcommand have to behave differently.

So it's a matter of priorities. Which is more important? Congruent behavior or local macros? My choice would be to keep a local \def.

ronkok on 18 Nov 2020

we can clear \current@color at the end

Agree 100%. My disagreement is not about color.

ronkok on 18 Nov 2020

\gnewcommand

This adds cognitive load to each and every author. Seems unnecessary to me.

ronkok on 18 Nov 2020

The whole point of globalGroup was to create something that behaved differently than LaTeX.

To me, globalGroup isn't that far a deviation from LaTeX -- it is (or can be viewed as) trying to simulate LaTeX's preamble mode (or outer par/text mode), where everything naturally evaluates in the global group. Perhaps it would be better if, instead of globalGroup, we had a top-level mode (at the level of align and so on that you added recently) of preamble. So then usage might look like:

\begin{preamble} 
\newcommand\foo{...}
\end{preamble}

I haven't thought too deeply about this though. It would help to know how people are actually using globalGroup. I fear they're setting it to true for all invocations to KaTeX which ... doesn't match my mental model of how it "should" be used.

Which is more important? Congruent behavior or local macros? My choice would be to keep a local \def.

My general preference is congruent behavior with LaTeX. I feel like changing macro definition behavior is a pretty slippery slope to full incompatibility. (And maybe I should have spoken more forcefully when globalGroup was being discussed, because that's where the deviation started... but I don't think any of us saw the full implications.)

To be more explicit: I really don't like the idea of $\gdef\foo{1}$ $\newcommand\foo{2}\foo$ $\foo$ changing behavior between strict set to true and false. PR #2640 would make this output 2 2 with strict: false, whereas the LaTeX-correct answer is 2 1 (and is presumably the intent of anyone who wrote that code). I'm fine with strict: false ("flexible mode") making some things possible that aren't possible in LaTeX, but I don't like it changing the meaning of possible things.

I could see a compromise of an option like newCommandIsGlobal (to maybe replace globalGroup), which when set true basically redefines \newcommand to a hypothetical \gnewcommand. (It'd also be nice to have \gnewcommand so that we could use it when newCommandIsGlobal isn't set.) This could be implemented almost exactly like the backwards-compatability option colorIsTextColor, which is implemented ... via a macro, "\\color": "\\textcolor". 🙂 Of course, we could also just provide \gnewcommand and suggest anyone who wants a global \newcommand could provide their own macro "\\newcommand": "\\gnewcommand".