# brucemiller/LaTeXML

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

# Infinite loop while Building #951

Closed
opened this Issue Feb 25, 2018 · 9 comments

## Comments

Projects
None yet
2 participants
Collaborator

Collaborator

### dginev commented Feb 25, 2018

 Debugging some more, the current master claims that: ltx:p can contain ltx:rect with a ltx:text intermediary a direct canContain call however, returns false for ltx:text can contain ltx:rect So there may also be a schema tweak needed. I will focus on ensuring schema mismatches don't lead to infinite loops in general until @brucemiller imparts schematic wisdom here, as a general case guard.
Owner

### brucemiller commented Feb 25, 2018

 Problem with naming closeText_internal just closes a "text" node (ie. PCDATA), not an ltx:text element. What's bizarre is that it would need to open ltx:picture to place a ltx:rect, but picture has autoOpen=>0.5 ! Presumably that means it's not preferred? Who wrote this stuff! I guess what's happening is that canContainIndirect says yes, but canContain says no!?!?!
Collaborator

### dginev commented Feb 25, 2018 • edited

 Ah! That naming distinction "threw me in for a loop". So ltx:text remains open and the two fighting methods are the autoclose vs autoopen, got it. I think I can add a guard that terminates early when a new auto-open attempts a name that has already been auto-closed (during a find_insertion_point recursive chain). Writing that PR now, will leave the mysterious autoOpen=>0.5 probabilistic magic to it creator :>
Owner

### brucemiller commented Feb 25, 2018

 Probably just need more threads... Not clear what's happening (computeIndirectModel is rather opaque, atm). Apparently canContainIndirect says ltx:rect CAN be inserted into ltx:p after opening ltx:text and ltx:picture; but says ltx:rect can NOT be inserted into ltx:text (not after opening ltx:picture)?

Closed

Collaborator

### dginev commented Feb 25, 2018

 Adding new thread where we can discuss the generic guard - now implemented at #952 Onto the specific framebox schema mystery in this issue. I can confirm your observations. I wish I understood the ltx:rect element a bit better in order to comment, but it is certainly an "inline" use in the source, in order to draw the QED rectangle, so depositing it inside a text element sounds reasonable at a glance.
Collaborator

### dginev commented Feb 25, 2018

 Also, it feels like we should add a schema-oriented test, using this \qed in text and math mode, to stay certain we have this nailed down going forward.
Owner

### brucemiller commented Feb 25, 2018

 Actually was a bit fishier: computeIndirectModel decided that you could open a ltx:text when trying to insert ltx:rect into ltx:text (or the other way 'round); in any case, it created potential cycles. Thanks for narrowing down the test case; should be fixed now!

Collaborator

 Sweet!

### dginev modified the milestones: LaTeXML-0.8.4, LaTeXML-0.8.3Feb 25, 2018

to join this conversation on GitHub. Already have an account? Sign in to comment