Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 04 19:10
    dependabot[bot] labeled #2
  • Dec 04 19:10
    dependabot[bot] opened #2
  • Dec 04 13:43
    pontusgranstrom opened #742
  • Dec 03 14:43
    arnog labeled #724
  • Dec 03 14:43
    arnog commented #724
  • Dec 03 12:58
    alexprey commented #724
  • Dec 03 11:13
    arnog commented #741
  • Dec 03 11:11
    arnog commented #736
  • Dec 03 10:55
    Kydyralin commented #736
  • Dec 03 09:44
    okeoke85 commented #741
  • Dec 03 09:43
    okeoke85 commented #741
  • Dec 02 15:01
    Kydyralin commented #736
  • Dec 02 15:01
    arnog labeled #740
  • Dec 02 15:00
    arnog commented #740
  • Dec 02 14:29
    arnog commented #741
  • Dec 02 13:52
    okeoke85 closed #741
  • Dec 02 13:52
    okeoke85 commented #741
  • Dec 02 12:52
    okeoke85 edited #741
  • Dec 02 12:32
    okeoke85 opened #741
  • Dec 02 10:40
    cao-minh-duc opened #740
Arno Gourdol
@arnog
The ongoing MathML work is interesting. There are two tracks: contributing another implementation to Chromium (there was one that was ripped out a while ago), and revising the MathML spec to address a number of the issues in the previous spec. This new version is called "MathML Core" and that's what's being implemented for Chromium. It's unclear if the other browser vendors will do the work to adopt MathML Core or will just keep their previous implementation. My understanding is that the previous implementations are supposed to be backward compatible in the sense they could parse MathML Core, but the rendering may be different. It would represent a big chunk of work to switch the Mathlive renderer (it's about 1/3 of the Mathlive codebase), and it's not clear what benefits it would offer. If I was to rewrite the renderer, I would rather switch to a pure SVG solution, which would make it easier to implement multiline rendering.
stefnotch
@stefnotch
You're welcome! I mostly started contributing, because I really want to have a top notch mathematical editor :smile:
Great!
Ok, I'll add some code to specifically handle the backspace case and submit a PR.
I mostly asked out of curiosity. I suppose one benefit would be that mathlive possibly wouldn't have to ship any font files with it anymore.
Arno Gourdol
@arnog
unfortunately, afaik, mathml core will still require a math font to be downloaded. There have been efforts to get either the browser vendors or the OS vendors to ship math fonts by default, but there has been little interest so far. If that does change, the current mathlive renderer could take advantage of that without a rewrite to mathml, though.
stefnotch
@stefnotch
Oh, that's a shame.
By the way, is it a bug that (a) results in ["Group", ["Subsequence", "a"]]]?
That (a,b) results in ["Group",["Subsequence","a","Nothing","b"]] is definitely a bug.
Arno Gourdol
@arnog
Yes, it's a bug. The Subsequence should not be there. Or the Nothing.
The Subsquence is only intended to be there in cases like this: (a, b, c; d, e, f)
stefnotch
@stefnotch

Out of curiosity, how's mathjson coming along? Regarding mathjson, once it becomes the internal format, would it make sense to tie some of the inputting/editing to a translation dictionary? For example, mathlive should only allow you to input vectors, if they are actually in the dictionary/can be parsed.

I'm currently most interested in fixing some of the editing issues, while waiting for more mathjson improvements :smile: e.g. the behavior of placeholders #369, one dimensional vectors #350 and backspace and caret moving issues #115 #116 #616 #615. I suppose fixing one of them would teach me enough about to code base to be able to fix a few other, or at least give me an idea of how to approach it.

Arno Gourdol
@arnog
it's coming along well. I've been working on some adjacent issues, involving the mathlive.io website (I'm going to have to rewrite its compute engine, but the good news is that I'll take advantage of this to publish it). I'm also about to move mathjson to its own separate project (so that you can use mathjson on its own, even if you're not using the mathfield)
"would it make sense to tie some of the inputting/editing to a translation dictionary" that's something I've been thinking about as well. It would make sense, but I'm not 100% sure how to handle it right now. Certainly, some latex macros could be "auto-defined" based on the mathJSON dictionary, but for some constructs, like vectors/matrix, it's less clear how to do that mapping.
#369 is a good one. I thought I had added some hints on how to proceed, but I see they're not there. Let me do that right now.
Arno Gourdol
@arnog
I'm sure I had added that comment somewhere. Maybe I wrote it in the wrong issue. Anyway, it's there now.
Arno Gourdol
@arnog
There's lots going on with #350 :) Maybe your suggestion is a good solution... Might be also useful as suggested by @saivan, to have a config option to enable/disable matrixes/vectors
re: #115, I like your suggestions, except I'm not entirely comfortable with the backspace key just moving the cursor. I like the "rule" from @dominique-unruh: "When I type backspace, it deletes something my cursor touches". I think consistency is imporant, and in cases where deleting something doesn't make sense, I think I'd rather have backspace do nothing rather than move the cursor. But maybe that's something worth playing with....
Arno Gourdol
@arnog
re #116: I'm not sure the current behavior is that bad. If we were to change the behavior, I would go with doing nothing, but that seems less helpful than the current behavior. Again, maybe I'm wrong here. It would be interesting to get feedback from some users.
#615 is a bug. There might be a problem with a skipBoundary being set for this (and related) commands when it shouldn't...
#616 sounds related. But maybe there's something else going on...
stefnotch
@stefnotch

Woah, that sounds amazing!
Moving mathjson to a separate project sounds like a great idea! That's going to make it much easier to adopt the fancy mathjson format in other projects as well.
Yep, it's definitely far from trivial. I currently don't have any good ideas regarding how to solve that.

Thank you for all the comments regarding the issues! Regarding the ones where the best option is still not entirely clear (e.g. "except I'm not entirely comfortable with the backspace key just moving the cursor"), I suppose that it'll become a bit clearer after having some actually working implementations and then testing them out.

Arno Gourdol
@arnog
Yes, for those where the best answer is not clear, it's worth implementing some options, preferably behind a feature flag, so that alternatives can be tested. And, again ideally, those could be tested with end users to get some feedback.
stefnotch
@stefnotch

It seems like skipBoundary is currently a bit buggy when something doesn't have any content.
e.g. 33+\ddot{}+44 (put your cursor at the beginning and keep tapping the right arrow key)

What should the correct behaviour be?

Arno Gourdol
@arnog
hmmm... indeed. It should be the same behavior as when pressing the left arrow key (but in reverse)
stefnotch
@stefnotch

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}6 and 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[]{}3 and 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?

Arno Gourdol
@arnog
One issue is that the code to traverse the tree is messy. There are multiple code paths that should do the same thing (moving forward and moving backward) and almost do, but not quite...
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
Arno Gourdol
@arnog
This means that whatever changes for the ordering (like swapping the index and root of surds) could be done in one place, PositionIterator and it would work for both forward and backward movement.
stefnotch
@stefnotch
Great! That sounds like a major improvement. I'll have to take a look at it later :smile:
Arno Gourdol
@arnog
Hmm... actually I just noticed that IteratorPosition does not account for skipBoundary but it probably should, and with better logic than currently to account for things like \ddot{} (i.e. skipBoundary atoms with no children).
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.
Arno Gourdol
@arnog
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.
stefnotch
@stefnotch

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.

Arno Gourdol
@arnog
oh, I see. Fair enough...
Hmmm... I'm wondering if the correct test here wouldn't be to check for skipBoundary rather than the type...
Arno Gourdol
@arnog
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.
stefnotch
@stefnotch
That does sound really nice, I'm looking forward to it! :)
Juan S. Escobar
@escobar5
Hi everyone
Anybody has used MathLive on CKEditor? any plugins out there?
Arno Gourdol
@arnog
Don't know of one yet, but let us know if you find something!
stefnotch
@stefnotch
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.)
Arno Gourdol
@arnog
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.
stefnotch
@stefnotch
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.)
Arno Gourdol
@arnog
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.