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

Improve JS spacing #1103

Merged
merged 11 commits into from
Feb 13, 2018
Merged

Improve JS spacing #1103

merged 11 commits into from
Feb 13, 2018

Conversation

ylemkimon
Copy link
Member

@ylemkimon ylemkimon commented Jan 27, 2018

  • Remove dummy spans for spacing around \href: Spacing around \href(anchor) is handled in the html.buildExpression, and currently spacings around \href are duplicated
  • Make bin cancellation aware of children of fragment and anchor
  • Fix tight spacing not applied: Fix spacing code for "tight" styles #1102 Fixed by use correct spacing with tight styles #1106
  • Add surrounding argument to html.buildExpression: it is an array consisting type of nodes that will be added to the left and the right, and if given, will be used to determine bin cancellation and spacings of outermost nodes. See delimsizing.js for its usage.

TODO:

Spacing around \href is handled in the `buildHTML`
It is an array consisting type of nodes that will be added to the left
and the right, and if given, will be used to determine bin cancellation
and spacings of outermost nodes.
@@ -161,7 +159,8 @@ defineFunction({
},
htmlBuilder: (group, options) => {
// Build the inner expression
const inner = html.buildExpression(group.value.body, options, true);
const inner = html.buildExpression(group.value.body, options, true,
[null, "mclose"]);
Copy link
Member

Choose a reason for hiding this comment

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

This seems to be the on place where the surrounding param is used. Do you for other situations where we'll need the first value instead of just the second?

Copy link
Member Author

Choose a reason for hiding this comment

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

@kevinbarabash Not yet, but I think it makes sense to have for both sides.

src/buildHTML.js Outdated
nonSpaces.unshift(surrounding[0] &&
new makeSpan([surrounding[0]], [], options));
nonSpaces.push(surrounding[1] &&
new makeSpan([surrounding[1]], [], options));
Copy link
Member

Choose a reason for hiding this comment

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

Is it necessary to create the spans if surrounding[0] or surrounding[1] is null or undefined?

Copy link
Member Author

Choose a reason for hiding this comment

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

@kevinbarabash It's for easy manipulation of nonSpaces. This way, we can safely assume that nonSpaces[0] and nonSpaces[nonSpaces.length -1] are dummy spans.

Copy link
Member

Choose a reason for hiding this comment

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

I would rewrite this as:

const nonSpaces = [
   surrounding[0] && makeSpan([surrounding[0]], [], options)),
   rawGroups.filter(group => group && group.classes[0] !== "mspace"),
   surrounding[1] && makeSpan([surrounding[1]], [], options)),
];

This avoids the unshift which could be costly depending on the length of the array and better shows that the surrounding array is being used to surround something.

Note: new isn't required for makeSpan.

Copy link
Member

Choose a reason for hiding this comment

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

I can't wait until we have everything converted to flow so that we can better enforce some of these assumptions.

const dimension =
calculateSize(activeSpacings[lastChildType]["mclose"], options);
glue.style.marginRight = `${dimension}em`;
inner.push(glue);
Copy link
Member

Choose a reason for hiding this comment

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

Now this isn't included in inner/children. Won't that affect the results of getOutermostNode?

Copy link
Member Author

Choose a reason for hiding this comment

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

@kevinbarabash The html.buildExpression inserts the appropriate spacing between the last child and mclose.

Copy link
Member

Choose a reason for hiding this comment

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

That's pretty cool. Glad you were able to figure out a way to get all the spacing code in one place.

}
}
return new buildCommon.makeAnchor(href, classes, elements, options);
return new buildCommon.makeAnchor(href, [], elements, options);
Copy link
Member

Choose a reason for hiding this comment

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

Nice!

const right = getOutermostNode(nonSpaces[i], "right");
if (right.classes[0] === "mbin" &&
isBinRightCanceller(nonSpaces[i + 1], isRealGroup)) {
right.classes[0] = "mord";
Copy link
Member

Choose a reason for hiding this comment

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

Nice!

@kevinbarabash
Copy link
Member

@ylemkimon are you still planning to do the TODOs in the top comment? Did you want me to comment on the code as is before adding tests/updating screenshots?

@kevinbarabash
Copy link
Member

whoops... wrong PR

@ylemkimon
Copy link
Member Author

@kevinbarabash Yes, and if you don’t mind, yes, please. Though, I’m not sure what is best way to add spacings recursively for \href and \class in #1074.

src/buildHTML.js Outdated
*/
export const buildExpression = function(expression, options, isRealGroup) {
export const buildExpression = function(expression, options, isRealGroup,
surrounding = []) {
Copy link
Member

Choose a reason for hiding this comment

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

Maybe make this surrounding = [null, null]. I think eventually we'll want to enforce that this is a 2-tuple with flow.

Copy link
Member

@kevinbarabash kevinbarabash left a comment

Choose a reason for hiding this comment

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

LGTM. I think the TODOs in the summary could be handled in a separate PR.

@codecov
Copy link

codecov bot commented Feb 11, 2018

Codecov Report

Merging #1103 into master will increase coverage by 0.35%.
The diff coverage is 89.28%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1103      +/-   ##
==========================================
+ Coverage   79.01%   79.37%   +0.35%     
==========================================
  Files          59       59              
  Lines        3875     3865      -10     
  Branches      655      648       -7     
==========================================
+ Hits         3062     3068       +6     
+ Misses        672      662      -10     
+ Partials      141      135       -6
Impacted Files Coverage Δ
src/functions/href.js 72.72% <0%> (+34.63%) ⬆️
src/functions/delimsizing.js 65.85% <100%> (+1.8%) ⬆️
src/buildHTML.js 93.53% <92.3%> (+1.09%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9b2101f...44381dc. Read the comment docs.

Copy link
Member

@kevinbarabash kevinbarabash left a comment

Choose a reason for hiding this comment

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

A couple of minor nits before merging:

  • avoid push/unshift on nonSpaces
  • don't use new on makeSpan

@kevinbarabash
Copy link
Member

I tried checking the checkboxes but apparently you can't do that to checkboxes inside review summaries.

@kevinbarabash kevinbarabash merged commit 439cea3 into KaTeX:master Feb 13, 2018
@kevinbarabash
Copy link
Member

@ylemkimon thanks for the PR.

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.

2 participants