I was seeing issues with evaluations in the graphing calculator that we sometimes use a real minus sign and sometimes use a special unicode one. We should investigate what's going on and make sure that efficient latex updates use the correct minus sign. I think the issue was that mathquill started off with the special minus sign. Then the slider went positive. This caused the minus sign to disappear. When the number went back negative we used a different minus sign in the efficient update logic than mathquill originally inserted.

In (most?) browsers, double clicking a word selects it, and triple clicking selects an entire paragraph.

In MathQuill, double and triple clicking currently do nothing, as far as I can tell.

Proposal:

• Double clicking should select the least "math block" ancestor. This would be roughly similar to e.g. Shift-End from the keyboard, but would select an entire block instead of just the part of it that is to the right of the cursor

  mathquill/src/services/keystroke.ts

  Lines 56 to 58 in aab6ed2

  	case 'Shift-End':
  	ctrlr.selectToBlockEndInDir(R);
  	break;

• Triple clicking should select all in the current mathquill

This feature request is somewhat important to Desmos because Desmos had previously disabled mouse events on static mathquills, which allowed the user to get native selection behavior on static mathquills and in particular, allowed them to double or triple click on static mathquills used to display calculator expression evaluations.

Desmos is now using MQ's mouse events on static mathquills, which is an improvement in some ways, but turns out to be a regression in terms of double and triple click behavior.

Since the fork does not have an npm package, could it be merged back with the original repo?

I noticed that a number of the tests in test/visual.html don't work on the main branch, but do on before-remove-jquery

Tested on windows 10 and linux in Firefox and Chrome.

I managed to fix #235 the textcolor one (quoting issue when translating jquery to the new style), but I wasn't sure what was wrong in the other cases.

Clicking in \MathQuillMathField doesn't work

In test/visual.html the x^2+y^2 inside the square root cannot be clicked when using the main branch, but does work in before-remove-jquery.

In both branches you can use tab to get into the square root and edit, but mouse clicks only work on before-remove-jquery.

"Touch taps/clicks/mousedown to drag should work anywhere in the blue box:" but don't

Only clicking directly inside the MathField work. The larger outer box doesn't work for clicking.

Textcolor section doesn't work

"Colors should match their names: " but they are all black

"Nested \textcolor: the 2 should be red, the "a+" green, the 4 blue, and the "+b" green again. " but all are black

Selection test selects a different element

In before-remove-jquery the field in "Selection Tests" is selected, but in main it is the first field on the page.

Are you guys able to create an NPM user and update your CI config to publish the builds to the public NPM repository?
This would greatly improve the installation and update process for your library.
Currently, I need to download the source for the version I want, build and copy-paste the artifacts into my project to get things rolling.

Thanks & cheers!

Basically #129 but with autoCommands instead of autoOperatorNames.

There is a subset of autoCommands that just aren't useful in subscripts and only get in the way of typing other strings. For instance, trying to type x_{intercept} will expand the int into an integral sign inside the subscript and place your cursor in the lower limit, which is almost certainly not something you'd ever want.

The autoCommands that only result in a symbol substitution (x_{beta} -> x_{β}) are useful. They might be slightly annoying in some situations (P_{pink} -> P_{πink}), but they're still useful: alpha beta theta phi pi tau infinity infty.

The autoCommands that "expand" are only annoying (ans doesn't expand, but no need to un-italicize it): sqrt nthroot cbrt sum prod int ans percent. For these, we should prevent the default behavior inside of simple subscripts.

Repro:

Try pasting \overleftrightarrow{AB} into the calculator on

• Desmos API v1.6: https://www.desmos.com/api/v1.6/docs/index.html
• Desmos API v1.7: https://www.desmos.com/api/v1.7/docs/index.html

v1.6

v1.7

I suspect this regressed when we merged mathquill/mathquill into desmosinc/mathquill in #164

Too many times I've watched people highlight (2,3) and type ( expecting to get blank parens and instead getting ((2,3)).

Because it's so easy to open and close parens, it doesn't feel like highlight & type should wrap (like we do with square roots and fractions).

Final proposed designs:

If the highlighted content is wrapped in parentheses and you type the same kind of parentheses, it erases the content and you're left with empty (and hardened) parentheses instead of double-paren-wrapping the contents.

browser: Safari on iPadOS 13

Steps to Trigger Behavior

1. Go to an activity on teacher.desmos.com that has a math input using an iPad with updated OS.
2. Open a screen with math input
3. Focus in the math input

Expected Behavior

Our scientific keypad appears.

Actual Behavior

Nothing! The scientific keypad and native keypad do not show up.

Note from Eric in slack:

Hi Jason!

I'm Charles from the Safari and WebKit engineering teams at Apple.

We'd like to ask you to make a small change to your wonderful website desmos.com.

Desmos's math field editor on your calculator pages creates hidden textareas for text entry. We'd like to request adding an inputmode="none" attribute to these invisible textarea elements when you have your own virtual keyboard on screen. This indicates that your web page implements your own keyboard input control.

Thank you! Please let us know if you have any questions!

Best,
Charles

Some warning flags regarding symbols that I found while doing #273:

• \parallel, \nparallel, and \perp are in both advancedSymbols and basicSymbols
• advancedSymbols has \bigtriangledown but not \triangledown.

I opened mathquill#1006 only to find that development in that repo is dead. I would like to use an updated version from here but there are no downloadable releases, and the one in the upstream doesn't seem like it'll be updated anytime soon

The example configuration object at the top doesn't include all the configuration options listed below.

I'm not sure if something like this already exists internally, but as most of the people reading this probably know, the current state of the mathquill codebase is quite a mess. Thus, I think a simple TODO list could help us get this project to easier maintenance speed.

Note: I do think that a new release of MathQuill should probably be breaking to reduce any legacy backwards code (with a migration guide, of course)

TODO:

• Get all tests working (they seem to be broken at the moment)
• Port all tests to typescript to avoid catchable runtime errors
• Remove JQuery entirely
• Remove extra code in outro.js (part 1/3 for ES Module port)
• Implement eslint to force code restrictions (notably avoiding window.* and setting global variables w/ var * ignoring MathQuill) (avoid bleeding side effects for part 2/3)
• export MathQuill and associated variables (and entirely remove vars) (part 3/3)
• Remove circular dependencies
• Use a build tool such as esbuild (we may have to force file order at first)

And with that, MathQuill will be a proper module, which should allow it to connect to faster tooling, giving everyone involved a better developer experience.

If the upstream still can't be merged, it would be safe to assume that desmos should publish an NPM package for MathQuill.

I'm personally fine with doing the rest, but the tests completely broke and its quite a nightmare -- ill see what I can do about it.