Implement \verb by edemaine · Pull Request #614 · KaTeX/KaTeX

edemaine · 2017-01-09T17:50:29Z

Here's an implementation of \verb, following #588. As @gagern suggested, the main parsing happens in the lexer, followed by code in parseSymbol to handle commands starting with \verb.

Playing around with LaTeX, I found (and implemented) the following behavior:

\verb will treat a following newline character as the start/end character.
Otherwise, the \verb argument cannot have a newline in it.
\verb will treat a following space as the start/end character.

I'm pretty new to generating output in MathML and HTML, and struggled to get the mathtt font, so please check that code in particular...

gagern

Definitely a great first step, thanks! We will need to add a screenshot test for this, though. And I've added some suggestions you might want to consider, although none of them is a strict requirement as far as I am concerned.

gagern · 2017-01-10T09:08:29Z

src/Lexer.js

    "([ \r\n\t]+)|" +                                 // whitespace
    "([!-\\[\\]-\u2027\u202A-\uD7FF\uF900-\uFFFF]" +  // single codepoint
    "|[\uD800-\uDBFF][\uDC00-\uDFFF]" +               // surrogate pair
+    "|\\\\verb\\*([^\0]).*?(?:\\3|\n|$)" +            // \verb*


Why [^\0]? If you want any character, including newline, you may write that as [^]. If there is some special semantics for \0 it should be explained in a comment or the PR discussion.

I confirmed that \0 didn't work in LaTeX, with error message Text line contains an invalid character. But that's probably just TeX being unhappy with the character in general. I think it's better to allow \0, but I didn't know how. Thanks for the tip!

gagern · 2017-01-10T09:14:07Z

src/Lexer.js

    "([!-\\[\\]-\u2027\u202A-\uD7FF\uF900-\uFFFF]" +  // single codepoint
    "|[\uD800-\uDBFF][\uDC00-\uDFFF]" +               // surrogate pair
+    "|\\\\verb\\*([^\0]).*?(?:\\3|\n|$)" +            // \verb*
+    "|\\\\verb([^*a-zA-Z]).*?(?:\\4|\n|$)" +          // \verb unstarred


How about just writing .*?\\4 (and likewise for \\3)? The use of . already excludes \n, as well as \r, \u2028 and \u2029. I think that is a reasonable fit for how TeX does this, but [\n]*?\\4 would be conceivable as well. If the terminating delimiter is not found before the end of line, then this would simply fall through to the function name getting matched against \verb, so we could define a function of that name to report the error.

Detecting unmatched delimiters was my goal, but that approach works too. Changed.

gagern · 2017-01-10T09:15:08Z

src/Parser.js

            new ParseNode("textord", nucleus.text, this.mode, nucleus),
            false, nucleus);
+    } else if (nucleus.text.slice(0, 5) === "\\verb" &&
+               !nucleus.text.charAt(5).match(/[a-zA-Z]/)) {


How about /^\\verb[^a-zA-Z]/.test(nucleus.text)?

Much better.

gagern · 2017-01-10T09:18:52Z

src/buildCommon.js

+var makeVerb = function(group, options) {
+    var text = group.value.body;
+    if (group.value.star) {
+        text = text.replace(/ /g, '\u2423');  // Open box


Is that symbol included in the tt font? Come to think of it, do we want to complain if the input contains any symbol not present in our tt font, as we can't guarantee consistent rendering or correct metrics for these?

It seems that the symbol is the wrong size, so probably not in the font... I thought that the usual "no metrics" warning would trigger in this case, but it seems not to, because I'm passing an entire string instead of individual characters. I changed the main code to look up characters one at a time, then try to combine them, as in text.

edemaine · 2017-01-10T14:56:50Z

I implemented your comments. (Thanks @gagern!) The last issue seems to be the space character in \verb*, which isn't in the mathtt font. Any ideas on how to fix this? Can we add it to the font, with proper spacing, somehow?

gagern · 2017-01-10T15:03:20Z

src/Parser.js

+        // Lexer's tokenRegex is constructed to always have matching
+        // first/last characters.
+        if (arg.length < 2 || arg.charAt(0) !== arg.slice(-1)) {
+            throw new ParseError("\\verb failure to parse");


What input would trigger this? Actually it might make sense to document error conditions in test/errors-spec.js.

No inputs would trigger this. I was treating it as an assertion before the next line which strips those characters. But I can also remove it if you prefer. I'll add an error test; thanks for pointing me to that.

gagern · 2017-01-10T15:11:45Z

While I have some rough ideas of how the font generation works behind the scenes, I haven't actually done that. What I understand is roughly this: The TeX fonts were taken, thickened, got unicode mappings and were saved to various font formats. The metrics were derived directly from the texmf metrics descriptions, but with some replacements. That part is included in our metrics directory. Some of the font generation was inherited from MathJax, but development forked off at some point, as far as I understand. Maybe https://github.com/Khan/MathJax-dev/tree/master/fonts is where all the magic happens, but I haven't looked closely at that yet. @kevinbarabash and @xymostech will know more.

By the way, your branch as it stands is difficult to review due to the merge from master. Can you rebase that on current master? git fetch origin && git rebase -i origin/master should do the trick, except you'll likely have some conflicts along the way and should resolve these appropriately.

edemaine · 2017-01-10T19:04:37Z

Rebased. Personally, I think we could merge this PR into master now, and turn the missing character into a separate issue. But I understand if you'd rather wait, or remove \verb* support until then.

gagern · 2017-01-10T22:01:10Z

I would be fine with this approach too, if we think we can get the character before the next release. I wouldn't want an incomplete feature in a release, since people may depend on behavior which won't be forward compatible. @kevinbarabash, can you judge how difficult adding that character will be? Should we disable the \verb* command for now? Apart from that, I'd like another look at the code now that it's rebased, but it's too late in the day around here.

k4b7 · 2017-01-11T03:32:20Z

It isn't too difficult, here are the steps:

modify https://github.com/Khan/MathJax-dev/blob/master/fonts/OTF/TeX/makeFF#L1500-L1529 to include the new character
follow the instructions in dockers/MathJaxFonts

It's been a while since I've done it so hopefully it all still just works. I checked my system and cmtt does indeed have metrics for character 32 which should be the space.

k4b7 · 2017-01-11T03:35:13Z

@edemaine give it a try. Once you check out https://github.com/Khan/MathJax-dev you should be able to run the command that the docker runs locally to test your changes out which should be:

cp MathJax-dev/default.cfg MathJax-dev/custom.cfg
make -C MathJax-dev custom.cfg.pl

gagern · 2017-01-11T11:20:58Z

@kevinbarabash I think we should have these steps documented somewhere. What do you suggest, Wiki or a README file in our repository or something else?

edemaine · 2017-01-11T14:39:12Z

@kevinbarabash I get the following error:

make ttf eot woff woff2
perl makeBlacker 15 # values between 10 and 30 seem best
Editing mftrace
Can't read '': No such file or directory
make: *** [lib/mftrace-modified] Error 2

caused by the following code in makeBlacker:

sub editMftrace {
  my $oldMFTRACE = $MFTRACE_PATH;
  $MFTRACE = "./lib/mftrace-modified";
  print "Editing mftrace\n";
  open(MFT,$oldMFTRACE) || die "Can't read '$oldMFTRACE': $!\n";

I can confirm that there is no lib/mftrace-modified. How does this get generated?

gagern · 2017-01-11T15:59:50Z

I see the Dockerfile and the corresponding README are in the KaTeX repo. Makes my request to have this documented boil down to adding a hint on how to add symbols.

I see that the Dockerfile does reference Google Code in a number of places. I'm currently trying to modernize that.

k4b7 · 2017-01-11T16:29:55Z

@edemaine not sure what's going on. I'll give it a try later today.

@gagern I'll post a set of working instructions, once I figure them out... probably on the wiki.

gagern · 2017-01-11T20:54:23Z

Check out #624 if you want to tweak the fonts. There you can use your own fork of the MathJax-dev repository, instead of the official one. It should even be possible to include git clone flags like --branch, but it should be in the same argument as the URL. Report on #624 if anything doesn't work as intended. Also report if it does, so that additional features you might use can get documented.

gagern · 2017-01-12T09:45:23Z

I've included a font that includes the space symbol, based on Khan/MathJax-dev#2. The \verb* looks good now, I'd say. I also noticed that the when using the unstarred version, the spaces are smaller than all the other glyphs. In the long run we should try to make the Teletype space equally wide. @kevinbarabash do you know where to tweak that?

gagern · 2017-01-12T10:11:17Z

src/buildHTML.js

+    var i;
+    for (i = 0; i < text.length; i++) {
+        body.push(buildCommon.makeSymbol(
+            text[i], "Main-Regular", group.mode, options, ["mathtt"]));


It feels a bit weird that \verb can handle input symbols which other commands can not, e.g. \mathtt{γ} doesn't work yet, but \verb|γ| does, with a warning to console, and \verb|“| doesn't even warn. Some might argue that incorrectly displaying a glyph is better than not displaying it at all, while others might worry about breaking existing content if we start supporting these symbols in the future.

So far (and in the context of unicode input) KaTeX chose the latter approach: don't support input unless you can do so in a compatible fashion. So perhaps we should filter for those symbols we actually have Typewriter metrics for?

If we take the other approach, and deliberately allow all symbols, even those we don't have fonts or metrics for, then it might be a good idea to consider surrogate pairs in this loop here. If the input contains a surrogate pair, then we want to keep the pair intact while building a symbol node from it.

I don't have strong feelings either way. Maybe I'm used to the warnings for unsupported symbols because of my experience with #618. 😄 I also feel like it's not crazy to pass through text of \verb mostly verbatim, but warning when that might do bad things. (If you like, that warning could be modified to warn of possible incompatibilities with future versions, i.e., don't rely on this behavior.) Anyway, let me know what you think is best and we can work on a tweak either way. (I'm afraid I don't actually know how to do the surrogate pair detection, or to fail when characters are not in the font, but I'm guessing that is done elsewhere in the code that I can mimic/re-use.)

gagern · 2017-01-12T10:12:57Z

test/screenshotter/ss_data.yaml

    errorColor: "#dd4c4c"
    nolatex: deliberately does not compile
+Verb:
+    \verb \verb , \verb|\verb|, \verb!<x> & </y>!


Now that we have ␣, there should be a \verb* in there as well. Perhaps use an array environment to provide multiple lines of content in a single screenshot.

Good ideas; done.

gagern · 2017-01-12T10:15:23Z

src/buildHTML.js

+            text[i], "Main-Regular", group.mode, options, ["mathtt"]));
+    }
+    buildCommon.tryCombineChars(body);
+    return makeSpan(["mord", "verb"], body, options);


Why the "verb" class? I don't see any specific styling for this. And the more classes we use in KaTeX, the more classes may not be usable by the surrounding page for their own purpose. Personally I'd even suggest prefixing all our classes with KaTeX- or some such, in order to avoid conflicts. Unless we do that, I'd be extra careful to only introduce new classes when we have to.

Both good points. I was imagining a user might want to style \verbs in some special way (like Github here does with backquotes), but it's a pretty hypothetical situation, and maybe not appropriate for LaTeX formatting, so probably not worth keeping this class. I'll remove it.

edemaine · 2017-01-12T15:24:22Z

@gagern Thanks for updating the font! The fontMetricsData.js you committed has trailing commas which eslint doesn't like. Should I be rebasing to es6 branch or new master, or should that be fixed upstream? (Presumably shouldn't fix it manually...)

I agree that the space in \verb| | is too short.

gagern · 2017-01-12T15:28:19Z

We've taught eslint to like (and in fact enforce) trailing commas again, in #622. Unfortunately the file is now in conflict, presumably with this. I feel all those comma changes were a pretty annoying detour, and will be happy once we no longer have any active branches without trailing commas. Until then we'll need to rebase – again.

edemaine · 2017-01-12T15:32:23Z

Indeed, looks like characters 2018 and 2019 were added to the typewriter font by someone else in the meanwhile. I assume those should be preserved. (Have you all been keeping your MathJax-dev repository in sync? It's a little disconcerting that I'm manually merging an autogenerated file...)

For reference, here's the diff:

<<<<<<< HEAD
        "2018": [0, 0.61111, 0, 0],
        "2019": [0, 0.61111, 0, 0],
        "8242": [0, 0.61111, 0, 0],
=======
        "8216": [0, 0.61111, 0, 0],
        "8217": [0, 0.61111, 0, 0],
        "8242": [0, 0.61111, 0, 0],
        "9251": [0.11111, 0.21944, 0, 0],
>>>>>>> ff241b1... Include space symbol in typewriter font, and fix single quotes

which I'm merging to the union

        "2018": [0, 0.61111, 0, 0],
        "2019": [0, 0.61111, 0, 0],
        "8216": [0, 0.61111, 0, 0],
        "8217": [0, 0.61111, 0, 0],
        "8242": [0, 0.61111, 0, 0],
        "9251": [0.11111, 0.21944, 0, 0],

edemaine · 2017-01-12T16:07:54Z

I was still getting "No character metrics" warning for ␣ until I realized \verb was using Main-Regular but needed to use Typewriter-Regular. Fixed. Now I properly get a warning that space ( ) has no character metrics defined, so maybe the fix is to define character metrics for it?

Somewhat related, I also get that * is not in the Typewriter font, which seems like an odd omission. Maybe worth reviewing which ASCII symbols are missing and adding them appropriately?

edemaine · 2017-01-12T17:02:23Z

Oops, * was failing only in \verb, not \texttt. I needed to switch \verb to text mode instead of math mode.

Typewriter font needs character metrics defined for space (32) and for no-break space (160). (I realized that \verb maps spaces to no-break spaces.)

k4b7 · 2017-01-13T01:22:40Z

I did some digging to see what LaTeX is doing for spaces in \texttt and \texttt{a b} results in the following:

\mathord
.\mathchoice
.D\mathord
.D.\hbox(6.11111+0.0)x15.74986
.D..\OT1/cmtt/m/n/10 a
.D..\glue 5.24995
.D..\OT1/cmtt/m/n/10 b
.T\mathord
.T.\hbox(6.11111+0.0)x15.74986
.T..\OT1/cmtt/m/n/10 a
.T..\glue 5.24995
.T..\OT1/cmtt/m/n/10 b
.S\mathord
.S.\hbox(4.27777+0.0)x11.15639
.S..\OT1/cmtt/m/n/7 a
.S..\glue 3.7188
.S..\OT1/cmtt/m/n/7 b
.s\mathord
.s.\hbox(3.05554+0.0)x7.96884
.s..\OT1/cmtt/m/n/5 a
.s..\glue 2.65628
.s..\OT1/cmtt/m/n/5 b

The glue for D and T styles matches the width of the the teletype characters which are 0.524995 em wide. Our ptPerEm variable corrects for the factor of 10 difference. The glue for S and s is different.

k4b7 · 2017-01-13T01:38:17Z

I also tried \verb!a b!\scriptstyle\verb!a b!\scriptscriptstyle!a b! and got the following:

\mathord
.\hbox(6.11111+0.0)x15.74986
..\OT1/cmtt/m/n/10 a
..\penalty 10000
..\glue 5.24995
..\OT1/cmtt/m/n/10 b
\scriptstyle
\mathord
.\hbox(6.11111+0.0)x15.74986
..\OT1/cmtt/m/n/10 a
..\penalty 10000
..\glue 5.24995
..\OT1/cmtt/m/n/10 b
\scriptscriptstyle
\mathord
.\hbox(6.11111+0.0)x15.74986
..\OT1/cmtt/m/n/10 a
..\penalty 10000
..\glue 5.24995
..\OT1/cmtt/m/n/10 b

which seems to indicate that spaces in \verb behaves different from in \texttt.

edemaine · 2017-01-13T01:57:48Z

@kevinbarabash \verb seems to ignore \scriptstyle and \scriptscriptstyle in LaTeX: they all appear at full size. $\verb|a b|\scriptsize\verb|a b|$ matches the glues from \texttt:

\mathord
.\hbox(6.11111+0.0)x15.74986
..\OT1/cmtt/m/n/10 a
..\penalty 10000
..\glue 5.24995
..\OT1/cmtt/m/n/10 b
\mathord
.\hbox(4.27777+0.0)x11.15639
..\OT1/cmtt/m/n/7 a
..\penalty 10000
..\glue 3.7188
..\OT1/cmtt/m/n/7 b

k4b7 · 2017-01-13T03:06:21Z

I didn't realize there was a \scriptsize in addition to \scriptstyle.

This is based on Khan/MathJax-dev#2 which hasn't been accepted yet at the time this commit is made.

edemaine · 2017-08-16T16:40:14Z

Revitalizing this PR:

Rebased
Implemented space support via manual spacing (like LaTeX does, but unlike how we deal with spaces elsewhere in KaTeX).
Fixed the issue I brought up earlier that \verb ignores the style and only handles the size, and updated the screenshotter test to confirm this.

Here's a texcmp:

I did not check whether characters are in the font, and rather rely on the warning that KaTeX produces about missing characters (see @gagern's old review, first comment). I'm not sure this is best. If someone agrees, I'll work on it. (I think I'd need to make a very simple custom lexer for the \verb string, and then mimic a small subset of parseSymbol.)

To encourage other people to review.

k4b7 · 2017-08-23T02:31:03Z

I was really confused as to why this was working b/c the visible space (open box) character doesn't show up in Apple's Font Book font viewing utility even though KaTeX appears to be rendering the glyph just fine. I tried opening KaTeX_Typewriter-regular in https://opentype.js.org/glyph-inspector.html and it shows up correctly. Not sure why Font Book wasn't displaying it.

k4b7 · 2017-08-23T02:34:17Z

In the font file the glyph is at position 0x20 which is normally the space. I looked at some other fonts and Font Book doesn't render the space in any of them which I guess makes sense b/c in other fonts it's blank so there's nothing to look at.

k4b7 · 2017-08-23T02:41:18Z

src/buildHTML.js

+            // 0.524995 is the width of a texttt character in LaTeX.
+            // It automatically gets scaled by the font size.
+            const rule = makeSpan(["mord", "rule"], [], newOptions);
+            rule.style.marginLeft = "0.524995em";


This could be 0.525em since the advance is 525 in font units.

k4b7 · 2017-08-23T02:45:59Z

src/buildHTML.js

+            // The space character isn't in the Typewriter-Regular font,
+            // so we implement it as a kern of the same size as a character.
+            // 0.524995 is the width of a texttt character in LaTeX.
+            // It automatically gets scaled by the font size.


This is unfortunate. One thing we might look at doing in the future is add a blank space character to the font so that we don't have to do this. That should allow us to use buildExpression like groupTypes.text does.

You suggested the reverse in #574. 😄 FWIW, TeX implements spaces as skips instead of characters, but I agree it'd be more symmetric (and simpler) to use a space character. I'm not sure where to collect together font issues -- perhaps on new font repo? Added KaTeX/katex-fonts#1

I forgot about that comment. I think the difference here is that \verb is kind of like \text and there we use real spaces. I think what you have here is fine.

k4b7 · 2017-08-23T02:50:20Z

src/buildCommon.js

+    if (group.value.star) {
+        text = text.replace(/ /g, '\u2423');  // Open Box
+    } else {
+        text = text.replace(/ /g, '\xA0');    // No-Break Space


I'm curious why a non-breaking space vs. a normal space.

\verb|hello world| will not break in LaTeX, and furthermore renders as multiple spaces, whereas the usual behavior for invisible spaces is that they combine into one. (Even within backtick mode in GFM, I had to use nonbreaking spaces to get them to not merge.) Added a comment to this effect.

I'm less clear on why I write it as \xA0 here and (formerly) in buildHTML.js. Probably the former is clearer, so I've changed the latter. Not sure if we have a preferred style on this matter.

k4b7 · 2017-08-23T02:55:08Z

src/Parser.js

+            if (arg.length < 2 || arg.charAt(0) !== arg.slice(-1)) {
+                throw new ParseError("\\verb failure to parse");
+            }
+            arg = arg.slice(1, -1);


I forgot for a second that negative indices to slice behave like negative indices in python.

Added a comment.

k4b7 · 2017-08-23T02:59:29Z

src/Parser.js

+            // Lexer's tokenRegex is constructed to always have matching
+            // first/last characters.
+            if (arg.length < 2 || arg.charAt(0) !== arg.slice(-1)) {
+                throw new ParseError("\\verb failure to parse");


This could error message could be more precise. In the case of arg.length < 2 the error could be:

`\\verb missing matching delimiter '${arg.charAt(0)}'`

and in the case of arg.charAt(0) !== arg.slice(-1) it could be:

`'${arg.slice(-1)}' doesn't match initial delimiter '${arg.charAt(0)}'`

This is actually more of an assertion: the regex should guarantee that that error is never thrown. The actual error that will get thrown is \\verb ended by end of line instead of matching delimiter which is more descriptive. (It doesn't mention the delimiter character, but that is not trivial to add... Let me know if I should work on it.)

I thought the first and last characters of the arg were the delimiter so it seemed like a trivial change to add those characters to the error message. If this case should never happen it's probably more important to say in the error that this is a bug and that it should be reported as such.

Rewrote the error message.

k4b7 · 2017-08-23T03:04:01Z

src/buildCommon.js

+/**
+ * Combine as many characters as possible in the given array of characters
+ * via their tryCombine method.
+ */


Maybe this should be:

const tryCombineTextNodes = function(nodes) {

It's possible that we might also get passed a documentFragment so we should probably add a tryCombine method on that class as well just in case.

k4b7 · 2017-08-23T03:06:22Z

test/errors-spec.js

+        it("complains about mismatched \\verb with end of line", function() {
+            expect("\\verb|hello\nworld|").toFailWithParseError(
+                "\\verb ended by end of line instead of matching delimiter");
+        });


Is there a way to test the exception being throw in Parser.js?

I'm confused -- isn't that what this is doing? Or do you mean confirming that the error is actually of type ParseError? We could probably rewrite toFailWithParseError to do this.

This is the error that's being thrown in functions.js. The error thrown in Parser.js has the text "\\verb failure to parse".

From your comment above it sounds like it should never happen though, so I guess we can't test for it.

Oh, I see. As described above, that error can never be thrown.

k4b7 · 2017-09-14T01:48:11Z

@edemaine friendly ping. I left some comments and there are a few merge conflicts, but I think this PR is pretty close to being done.

Resolve conflicts

edemaine · 2017-09-19T16:05:59Z

@kevinbarabash Sorry for the delay (been tied up lately), and thanks for the reminder. Just merged with master, and added one commit addressing your comments. Hopefully good to go now.

k4b7 · 2017-09-22T00:35:55Z

The screenshots need to be regenerated... probably b/c of that change from 0.524995 to 0.525.

k4b7

Code looks good.

edemaine · 2017-09-22T02:30:09Z

Thanks! Sorry for the screenshot oversight.

edemaine mentioned this pull request Jan 9, 2017

Support for \verb #588

Closed

gagern requested changes Jan 10, 2017

View reviewed changes

gagern reviewed Jan 10, 2017

View reviewed changes

edemaine force-pushed the verb branch from 198dd08 to bd6e575 Compare January 10, 2017 16:13

gagern mentioned this pull request Jan 11, 2017

Modernize font creation #624

Merged

gagern mentioned this pull request Jan 12, 2017

Make ␣ available in Typewrite font, and fix ‘ and ’ Khan/MathJax-dev#2

Merged

gagern force-pushed the verb branch from a7cdc6a to ff241b1 Compare January 12, 2017 10:03

gagern previously requested changes Jan 12, 2017

View reviewed changes

edemaine force-pushed the verb branch from ff241b1 to 8e13098 Compare January 12, 2017 15:33

edemaine and others added 8 commits August 16, 2017 11:23

Add error tests for \verb

bb31e8f

Include space symbol in typewriter font, and fix single quotes

ba83c4f

This is based on Khan/MathJax-dev#2 which hasn't been accepted yet at the time this commit is made.

Add \verb* tests

cbc3c48

\verb should use Typewriter-Regular font!

fa7eed5

Switch \verb to use text mode and no-break space.

524b921

Screenshot update with Typewriter-Regular

e85a28a

\verb test: fix *, add commas to make spaces clear

4fab828

Fix spaces and style handling

59814a4

edemaine force-pushed the verb branch from dc66eb5 to 59814a4 Compare August 16, 2017 16:31

edemaine added the GH Review: review-needed label Aug 20, 2017

k4b7 reviewed Aug 23, 2017

View reviewed changes

Merge branch 'master' into verb

dd26806

k4b7 added GH Review: needs-revision and removed GH Review: review-needed labels Sep 14, 2017

edemaine added 2 commits September 19, 2017 11:26

Merge remote-tracking branch 'upstream/master' into verb

a28754a

Resolve conflicts

Implement @kevinbarabash's comments

da52668

edemaine mentioned this pull request Sep 19, 2017

Typewriter font missing regular space KaTeX/katex-fonts#1

Closed

Make error clearly an assertion failure

5884171

k4b7 approved these changes Sep 22, 2017

View reviewed changes

verb screenshot for Chrome

21558d1

Merge branch 'master' into verb

679a287

k4b7 merged commit f10ea4c into KaTeX:master Sep 22, 2017

Uh oh!

Conversation

edemaine commented Jan 9, 2017

Uh oh!

gagern left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

edemaine commented Jan 10, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gagern commented Jan 10, 2017

Uh oh!

edemaine commented Jan 10, 2017

Uh oh!

gagern commented Jan 10, 2017

Uh oh!

k4b7 commented Jan 11, 2017

Uh oh!

k4b7 commented Jan 11, 2017

Uh oh!

gagern commented Jan 11, 2017

Uh oh!

edemaine commented Jan 11, 2017

Uh oh!

gagern commented Jan 11, 2017

Uh oh!

k4b7 commented Jan 11, 2017

Uh oh!

gagern commented Jan 11, 2017

Uh oh!

gagern commented Jan 12, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

edemaine commented Jan 12, 2017

Uh oh!

gagern commented Jan 12, 2017

Uh oh!

edemaine commented Jan 12, 2017

Uh oh!

edemaine commented Jan 12, 2017

Uh oh!

edemaine commented Jan 12, 2017

Uh oh!

k4b7 commented Jan 13, 2017

Uh oh!

k4b7 commented Jan 13, 2017

Uh oh!

edemaine commented Jan 13, 2017

Uh oh!

k4b7 commented Jan 13, 2017

edemaine Sep 19, 2017 •

edited

Loading