Now, I don't want the issues that I'm taking a look at to balloon in scope, but after taking a look at the model-select, model-delete and related code, I've stumbled upon quite a few things. (some of them are quite subjective)
- skipBoundary is buggy for things like
\ddot{} - skipBoundary is buggy for nested
3+\ddot{\ddot{\ddot{3}}}+4, for example deleting it doesn't work as expected 3\stackbin{4}{5}6and tapping the left arrow key results in a slightly different order to tapping the right arrow key (the spot after the 4 gets skipped over)3\xrightarrow[]{}3and tapping the left arrow key results in a bottom placeholder but not a top placeholder\sqrt[3]{4}and tapping the left arrow key results in a, for me, slightly unexpected order. I expected it to first let me edit the 4 and then the 3.- 'overunder' atoms like \utilde{3333} cannot be deleted without deleting the content, because of the skipBoundary. Maybe that's fine.
- Then there is
xrightarrow, which really doesn't feel like an overunder atom. It feels more like a mop atom, just like the sum.
On whole, I'm not sure, maybe the code ties the latex representation too close to the editing part?
A solution for that is to have a single, canonical, place that does the iteration, and have everywhere that needs to know what is "next" or "previous" use that same code
Luckily, I just checked-in something along those lines :) Well, a beginning of it anyway.
There is now a
PositionIterator class in model-iterator.ts
It calculates in order all the possible "spots" where the cursor can be, and it is then possible to move forward and back from the current spot
I had to add this because of the new API to get access to the selection, i.e.
mf.getValue(mf.selection)
That's the good news. The bad news is that there are still some places in the code that use the "old" method. In particular, I haven't touched to
next() and previous(), but they are ripe for simplification and using PositionIterator instead of the code they currently have
3\xrightarrow[]{}3 good point. I think the logic is that the optional argument is skipped, but then that means there's not easy way to edit it. If changing this logic, that means that it would apply for \sqrt{} as well (which would always have an the index editable). Maybe that's OK, although that could be surprising for some users too...
xrightarrow is an overunder atom because the overunder atom knows how to draw and stretch the body with SVG. The kind of atom doesn't really influence the editing, though, it's really just what rendering routine gets invoked.
In general, the way selection is represented internally (with "paths" and "extent) is pretty messed up. I don't know what I was thinking when I came up with this. It's code that's both convoluted and fragile. Using a simple pair of indexes (start, end) to represent the selection would be much simpler. Now that
PositionIterator is here, I hope over time to rip out the path based code. One thing that might be needed is to add a parent property to Atom, otherwise without path there isn't an easy way to go "up" in the node tree.
Actually, the reason why I did it this way in the first place is that TeX doesn't have pointer to parent nodes either. It's fine for rendering (when you really only need to descend the tree), but for editing, you need the parent pointer.
I suppose that being able to edit the index of a sqrt isn't too surprising, but opening an issue on GitHub (and hopefully getting feedback) is always an option.
Well, the type does make a difference right here (model-delete.ts)
if (/^(group|array|genfrac|surd|leftright|overlap|overunder|box|mathstyle|sizing)$/.test(model.sibling(1).type) ) {
move(model, +1);
} else { ...Hooray, the mathlive code is going to become simpler! :tada: I'm looking forward to it.
Hmmm... I'm wondering if the correct test here wouldn't be to check for
skipBoundary rather than the type...
heads up: I'm rewriting the way the selection works in MathLive. I'm moving away from paths and using an index-based selection instead. I expect the rewritten code will be much easier to read and debug, and it will be easier to change some of the selection and keyboard navigation behaviors.
Anybody has used MathLive on CKEditor? any plugins out there?
Out of curiosity, how's it going?
(I've stumbled upon another project where something like mathjson would be really useful and looked far and wide before deciding that I'll probably have to implement a dirty hack, because all the alternatives are meh and mathlive's mathjson is sadly not yet done.)
(I've stumbled upon another project where something like mathjson would be really useful and looked far and wide before deciding that I'll probably have to implement a dirty hack, because all the alternatives are meh and mathlive's mathjson is sadly not yet done.)
I have jumped into a rabbit hole. I've been investigating some of the open issues regarding editing behavior, selection, and matrix editing and I've come to the conclusion that the current implementation is not going to cut it. So I've been hard at work on reimplementing the way selection works. It's a big job, but I'm making progress and fixing bugs along the way. I just want to make sure I don't introduce regressions and there are a lot of test cases to consider. The good news is that once I'm done new things will be possible, for example applying styles to arbitrary portions of an expression, being able to search an expression (for example "find all the x to a power"), and, importantly, do things like "select a column in a matrix". In the meantime I've also extracted MathJSON. I'll publish it to a separate GitHub repo shortly.
Haha, jumping into rabbit holes also constantly happens to me. Glad to hear that it's going quite fine!
(Searching an expression is going to be so powerful. It would make it quite possible to write a really neat expression rewriter. Like "find all a^3" and then the rewriter figures out how to combine/factor them.)
(Searching an expression is going to be so powerful. It would make it quite possible to write a really neat expression rewriter. Like "find all a^3" and then the rewriter figures out how to combine/factor them.)
I have just pushed a pretty massive update to the main branch. This include several architectural changes, including a complete rewrite of how the selection works, and using sub-classes to isolate the behavior of the different kind of atoms (instead of having it spread out all across the codebase).
This is still a work in progress: the handling of arrays is busted right now, but that's coming next.
See the CHANGELOG for details.
Hello everyone and thanks very much for that great piece of software. I have a quick question: When defining an inlineShortcut, is it possible to make use of the preceding symbol, e.g. have a shortcut "vec" that will put an arrow over the last char? I can currently only define "\vec{#1}" leaving a placeholder, but then the user will have to "move out" of it, once they are done.
hi, there is an issue, the autocomplete pop-up (when we start typing "\somthing") the pop-up gets stuck and mispositioned. it only happens when using math-field tag or MathfieldElement constructor but no issue with makeMathField. i wanna use as tag, my question is there anyway that i can disable this feature in the options?
it's not impossible but the parsing of MathML is... non-trivial
I've just updated the cortexjs.io website with documentation on MathJSON (http://cortexjs.io/guides/math-json/) and the Compute Engine (http://cortexjs.io/guides/compute-engine/). MathJSON is pretty stable, and the Compute Engine is a work in progress on which I'm actively working.
I'm looking for feedback on a foundation of the Compute Engine, its domains (i.e. the "types" of mathematical objects it handles). If you have a minute, have a look at http://cortexjs.io/guides/compute-engine-domains/ and let me know what I got wrong, what's missing, or what doesn't need to be there. Note that domains (like everything else in Compute Engine) can be extended, so this list doesn't have to be exhaustive, but it should be large enough to be useful for "common cases".
This looks really good!
One type that I haven't seen in the list
- Finitary relations: Wikipedia has some pretty good examples, I suppose they might actually be useful in a compute engine https://en.wikipedia.org/wiki/Finitary_relation
Some other types that I haven't seen in that list would be (no idea how useful any of them would be)
- Quaternions: Programmers like using those to represent rotations
- Orthogonal matrix: Every rotation can also be represented with an orthogonal matrix
- Congruence Classes: Things like "odd" + "even" = "odd", but more general
- Recurrence relations: Basically functions that call themselves, like the Fibonacci function
I also feel tempted to point out that vectors are a very general concept and even polynomials can be treated as vectors (you can add them and you can multiply them by a scalar). Our mathematics professor very much liked those examples xD