Skip to content
New issue

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

SourceSpan support #123

Merged
merged 19 commits into from
Apr 27, 2018
Merged

SourceSpan support #123

merged 19 commits into from
Apr 27, 2018

Conversation

ForNeVeR
Copy link
Owner

@ForNeVeR ForNeVeR commented Apr 1, 2018

Closes #115.

This is a rebased version of PR #116. I will be fixing the tests here and polishing the changes.

TODO

@ForNeVeR ForNeVeR self-assigned this Apr 1, 2018
@ForNeVeR ForNeVeR changed the title [WIP] SourceSpan support [WIP] StringSpan support Apr 1, 2018
@ForNeVeR ForNeVeR changed the title [WIP] StringSpan support [WIP] SourceSpan support Apr 1, 2018
@ForNeVeR
Copy link
Owner Author

ForNeVeR commented Apr 5, 2018

Well, I've started removing Atom.Copy in favor of AtomWithSource and I have a feeling that something's wrong. Look: we have all these references all over the place (e.g. BigOperatorAtom referencing its' BaseAtom), and it looks like we should give this property a signature AtomWithSource BaseAtom { get; set; }

Our code will become a mess with slices of Atoms and AtomWithSources, I don't like that.

Looks like we should return back to the design board. Probably we will need that Atom.Copy after all? Maybe other guys' suggestion about rewriting everything in F# wasn't so radical as I thought?

Because, well, current problem is that we cannot get cheap class copying in C#, so we have to implement this Copy method in every Atom descendant, and I extremely dislike that. What could we do? Make everything struct? Will it work? Any other suggestions?

@alexreg
Copy link
Collaborator

alexreg commented Apr 5, 2018

@ForNeVeR As long as there are no many-to-one or one-to-many references (from memory I don't think so), then converting everything to value types (i.e. structs) would seem to make sense to me. You get efficient copying for free then.

@ForNeVeR
Copy link
Owner Author

ForNeVeR commented Apr 6, 2018

Yeah, working on it in a separate branch. We'll see what else we can do. I have some other ideas.

This commit intentionally won't compile.

# Conflicts:
#	src/WpfMath/Atom.cs
#	src/WpfMath/CharSymbol.cs
#	src/WpfMath/DummyAtom.cs
#	src/WpfMath/OverUnderDelimiter.cs
#	src/WpfMath/RowAtom.cs
#	src/WpfMath/SpaceAtom.cs
#	src/WpfMath/TexFormulaParser.cs
#	src/WpfMath/UnderOverAtom.cs
@ForNeVeR
Copy link
Owner Author

  • Add Box.SourceAtom, drop Box.Source

Now I'm not sure about that. Currently, all of our Atoms are internal classes, so we cannot publish them through a public member. And I'd keep it as is for the moment, because the Atom API will likely be unstable in the future.

We could mark only the root of the Atom type hierarchy as public, but I can't see a point for that: the only usable public members would be TexAtomType and SourceSpan. Basic Atom is useless if the user cannot see its' structure.

Hereby I revoke my requirement about adding Box.SourceAtom. For now, let's leave a Box.Source member intact.

@ForNeVeR
Copy link
Owner Author

ForNeVeR commented Apr 14, 2018

Also, we have some bugs here. @yamamoto-reki made the selected blocks to highlight themselves in the example project. E.g.

image
(the highlighting works well and it's accurate enough)

In my PR, it doesn't highlight some blocks and sometimes behaves weird:
image

Before merging, we'll need to fix that weirdness and make sure everything works well.

@@ -75,6 +94,18 @@ public ControlTemplate ErrorTemplate
"ErrorTemplate", typeof(ControlTemplate), typeof(FormulaControl),
new PropertyMetadata(new ControlTemplate()));

public static readonly DependencyProperty SelectionStartProperty = DependencyProperty.Register(
"SelectionStart", typeof(int), typeof(FormulaControl),
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to use nameof here!

@@ -49,18 +49,23 @@ public TexRenderer GetRenderer(TexStyle style, double scale, string systemTextFo
return new TexRenderer(CreateBox(environment), scale);
}

public void Add(TexFormula formula)
public void Add(TexFormula formula, SourceSpan source = null)
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The binary compatibility has been broken here, unfortunately (the source compatibility was preserved). We could fix that. Should we?

Copy link
Owner Author

@ForNeVeR ForNeVeR Apr 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think so. Hopefully nobody uses that API. And we're still in API-breaking period of our semver (0.x versions). And it's notoriously hard if not impossible to keep full source+binary compatibility when method overloads are involved.

@@ -1,341 +1,339 @@
using System;
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously this file had CRLF and now it has LF (it was replaced because I renamed it to match the class name). I think that's alright.

Please check the online diff with ?w=1 appended to the page URL to see the real changes (it will ignore the whitespace diff): https://github.com/ForNeVeR/wpf-math/pull/123/files?w=1#diff-e81f0c498a5c8d83d49d999c0375f718

@ForNeVeR ForNeVeR changed the title [WIP] SourceSpan support SourceSpan support Apr 15, 2018
@ForNeVeR ForNeVeR requested review from alexreg and gsomix April 15, 2018 06:08
@ForNeVeR
Copy link
Owner Author

Alright, it's ready for review, guys.

@yamamoto-reki could you also please take a look?

My next step will be to review (and probably merge) the remaining changes (BoxWalker, FormulaUtils) from your PR #116.


// TODO[F]: Review the cases where the formula gets constructed from this.Formula.RootAtom wrapped in something
// (e.g. SetFixedTypes): in these cases, it looks like we should clean the SourceSpan inside of a formula and
// set it for the new root atom only?
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please file an issue about that!

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #132.

Copy link
Collaborator

@gsomix gsomix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, that's very big PR...

🐐

@gsomix
Copy link
Collaborator

gsomix commented Apr 27, 2018

Great job!

@ForNeVeR
Copy link
Owner Author

Thanks for the review!

@ForNeVeR ForNeVeR merged commit baa74fd into master Apr 27, 2018
@ForNeVeR ForNeVeR deleted the feature/115-source-support branch April 27, 2018 16:12
@alexreg
Copy link
Collaborator

alexreg commented Apr 27, 2018

Good job with this, @ForNeVeR! Not a small task, but looks like really important work going forwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Give a range of source string to Box
4 participants