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

Support \hline #1306

Merged
merged 25 commits into from
May 12, 2018
Merged

Support \hline #1306

merged 25 commits into from
May 12, 2018

Conversation

ronkok
Copy link
Collaborator

@ronkok ronkok commented May 11, 2018

Support \hline. Fix #267, part of #269.

@codecov
Copy link

codecov bot commented May 11, 2018

Codecov Report

Merging #1306 into master will decrease coverage by 0.31%.
The diff coverage is 39.28%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1306      +/-   ##
==========================================
- Coverage   84.24%   83.92%   -0.32%     
==========================================
  Files          61       61              
  Lines        3973     4001      +28     
  Branches      662      665       +3     
==========================================
+ Hits         3347     3358      +11     
- Misses        532      546      +14     
- Partials       94       97       +3
Impacted Files Coverage Δ
src/environments/array.js 42.85% <39.28%> (-0.53%) ⬇️

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 929b9bf...0543f9e. Read the comment docs.

@ronkok
Copy link
Collaborator Author

ronkok commented May 11, 2018

Here's how they look:
hlinepic

@ylemkimon
Copy link
Member

The commit Support Unicode \ll and \lll seems to be mistakenly committed into the master branch and preventing merge from KaTeX master.

@edemaine
Copy link
Member

@ylemkimon I don't think it's actually a problem. @ronkok's last few PRs have been this way, and the old commits get swept up in the squash. At some point it'd be good to start new PRs from the master branch, though. (For me it's git checkout upstream/master; git checkout -b newbranch.)

@edemaine
Copy link
Member

@ronkok Wow, it's exciting to see how this is relatively easy thanks to stretchy \overline!

There are two natural features that aren't yet in this PR; is it worth adding them now?

  • \hline can be repeated to make multiple horizontal lines between rows. (I think it also interrupts the vertical lines... that may be harder to do, but could be skipped for now.) This would be good for "full \hline support".
  • \cline{3-5} does \hline only for columns 3 through 5. I'm guessing you have to render the horizontal line for each column separately anyway (because tables are rendered column-by-column), so this isn't too hard... But also not as important as \hline itself.

@ronkok
Copy link
Collaborator Author

ronkok commented May 11, 2018

@ylemkimon GitH(Hub) has been acting that way since I did manual edit on a merge conflict in the \ll PR. As soon as this PR and PR #1162 are merged, I'll dive in and fix my repository. Until then, I don't want to make any rash moves.

@ronkok
Copy link
Collaborator Author

ronkok commented May 11, 2018

@edemaine Later today, I'll add the double \hline. As you suggest, today's effort will not interrupt any vertical lines. I may also add a dotted \hline.

No promises on \cline. My currrent \hlines are not done column by column. I just let the browser stretch each one the full width of the array. In order to implement \cline, I would have to work my way deeper into the array parser. That may not happen in time for the next release.

possibleHLine = parser.nextToken.text;
}
if (possibleHLine === "\\hline") {
hlines.push(true);
Copy link
Member

Choose a reason for hiding this comment

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

Can group.value.addHLines = true; be done here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@ylemkimon Stand by. I've got a code cleanup commit coming in about an hour. It will change this section of the code.

while (/\s/.test(possibleHLine)) {
parser.consume();
possibleHLine = parser.nextToken.text;
}
Copy link
Member

@ylemkimon ylemkimon May 11, 2018

Choose a reason for hiding this comment

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

Could this be done by parser.consumeSpaces()? (same for above)

@ronkok
Copy link
Collaborator Author

ronkok commented May 11, 2018

Double \hlines:
hlinepic2

@ronkok
Copy link
Collaborator Author

ronkok commented May 11, 2018

Now I think this is ready for review. I will also need some help to create screenshots for Hline.

@edemaine
Copy link
Member

The screenshot renders as 1246x752, but needs to be at most 1024x768. Can you make it a little less wide, e.g., reducing the \quads?

@ronkok
Copy link
Collaborator Author

ronkok commented May 11, 2018

There's no point in cutting it close. One of the arrays was redundant and I took it out.

while (/^\s$/.test(next)) {
parser.consume();
next = parser.nextToken.text;
}
Copy link
Member

Choose a reason for hiding this comment

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

Could this be done using parser.consumeSpaces()?

Copy link
Member

Choose a reason for hiding this comment

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

Yes. Please use that instead.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Will do.

if (nextTokenIsHLine(parser)) {
numHLinesBeforeRow[0] = 2;
}
} else {
Copy link
Member

Choose a reason for hiding this comment

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

I think the following is more readable (same for below), but it's matter of personal preference:

    if (nextTokenIsHLine(parser)) {
        if (nextTokenIsHLine(parser)) {
            numHLinesBeforeRow.push(2);
        } else {
            numHLinesBeforeRow.push(1);
        }
    } else {

Copy link
Member

Choose a reason for hiding this comment

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

Is there something magic about 2? Why not a while loop and counter? Does LaTeX not support more than 2 \hlines?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Until just now, I had never tried more than two \hlines. while loop coming right up.

@ronkok
Copy link
Collaborator Author

ronkok commented May 12, 2018

And now, with multiple \hlines:
hlinepic

for (let i = 2; i <= numHLinesBeforeRow[0]; i++) {
totalHeight += 0.25;
hlinePos.push(totalHeight);
}
Copy link
Member

Choose a reason for hiding this comment

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

This can be simplified to (same for below):

    if (numHLinesBeforeRow[0] > 0) {
        totalHeight += 0.25 * (numHLinesBeforeRow[0] - 1);
        hlinePos.push(totalHeight);
    }

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@ylemkimon We need a loop in order to handle multiple \hlines. So I think you mean that the code could read something like:

    for (let i = 1; i <= numHLinesBeforeRow[0]; i++) {
        if (i >  1) {
            totalHeight += 0.25;
        }
        hlinePos.push(totalHeight);
    }

That would be simpler for a human to read. But force of habit makes me try to avoid putting conditional statements inside a loop. Maybe this is not the place for that kind of thing. After all, we're not likely to get very many \hlines.

Would you prefer my suggested revision to the current code?

Copy link
Member

Choose a reason for hiding this comment

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

@ronkok I thought hlinePos is added only once, sorry. I think we can leave as-is.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I thought hlinePos is added only once

Which goes to show that code I suggested above would indeed be easier for a human to read. The speed loss with so few \hlines is negligible. I'll make the change.

return true;
}
return false;
}
Copy link
Member

Choose a reason for hiding this comment

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

How about:

function getNumHLines(parser: Parser): number {
    let n = 0;
    parser.consumeSpaces();
    while (parser.nextToken.text === "\\hline") {
        parser.consume();
        n++;
        parser.consumeSpaces();
    }
    return n;
}

(or for loop if you prefer) and

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I like it.

// Test for \hline at the top of the array.
while (nextTokenIsHLine(parser)) {
numHLinesBeforeRow[0] += 1;
}
Copy link
Member

Choose a reason for hiding this comment

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

    const numHLinesBeforeRow = [];

    numHLinesBeforeRow.push(getNumHLines(parser));

(same for below)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's an outstanding suggestion. I'll do it.

@ronkok
Copy link
Collaborator Author

ronkok commented May 12, 2018

Once again, I'll need help to generate a screenshot for HLine. Sorry to be a burden.

@ronkok
Copy link
Collaborator Author

ronkok commented May 12, 2018

Thanks, @edemaine!

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.

3 participants