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

Parse sub-lists indented with tabs #347

Conversation

transitive-bullshit
Copy link

@transitive-bullshit transitive-bullshit commented Aug 8, 2018

Fixes #198.

@wooorm I have tested this change locally and it appears to work for sub-lists indented with space and tabs. With that being said, I wanted to get somebody's feedback on the minor changes before moving ahead with updating the test fixtures and adding tests to handle this use case.

See my discussion in #198 for a minimal repro case.

Thanks!

cc @sindresorhus sindresorhus/awesome-lint#29

padding = C_TAB;
} else {
padding = '';
}
Copy link
Author

@transitive-bullshit transitive-bullshit Aug 8, 2018

Choose a reason for hiding this comment

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

This logic for adding padding in a function that is supposed to be removing padding is definitely incorrect. I've checked the failing test cases before and after this change, and this code block does more harm than good. There is only one test case whose output changes after making this change, and the previous fixture expected it to introduce a phantom \t into the output text paragraph. By removing this block, the phantom \t is removed and the test output is correct afaict.

@@ -467,7 +468,7 @@ function normalListItem(ctx, value, position) {
$2 = C_SPACE + $2;
}

max = $1 + repeat(C_SPACE, $2.length) + $3;
max = $1 + repeat(C_SPACE, Math.max($2.length, TAB_SIZE)) + $3;
Copy link
Author

@transitive-bullshit transitive-bullshit Aug 8, 2018

Choose a reason for hiding this comment

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

This is necessary because we want to trim ensuing lines if they contain at least a \t, but if the first line doeesn't contain a \t, we won't properly trim them here.

I've looked through the changed (failing) test cases that this edit introduces, and afaict, their output fixtures were less correct before this change.

@transitive-bullshit transitive-bullshit changed the title remark-parse parse sub-lists indented with tabs Parse sub-lists indented with tabs Aug 8, 2018
@@ -432,7 +432,8 @@ function normalListItem(ctx, value, position) {

lines = value.split(C_NEWLINE);

trimmedLines = removeIndent(value, getIndent(max).indent).split(C_NEWLINE);
var maxIndent = getIndent(max);
Copy link
Member

Choose a reason for hiding this comment

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

could you move the var declaration to the top? So var maxIndent above, and maxIndent = getIndent(max) here?

package.json Outdated
@@ -26,6 +26,7 @@
"tape": "^4.5.1",
"uglify-js": "^3.0.28",
"unist-builder": "^1.0.2",
"unist-util-inspect": "^4.1.3",
Copy link
Member

Choose a reason for hiding this comment

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

Is this needed?

Choose a reason for hiding this comment

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

removed :)

@wooorm
Copy link
Member

wooorm commented Aug 19, 2018

@transitive-bullshit Nice! Could you run node script/regenerate-fixtures on this PR, so that we can discuss the changed fixtures?

@transitive-bullshit
Copy link
Author

Thanks @wooorm. PR updated accordingly.

@transitive-bullshit
Copy link
Author

There appears to be a lingering error that isn't solved by regenerating the fixtures, although it should be. I'm not sure what's going on in that case.

@wooorm
Copy link
Member

wooorm commented Aug 20, 2018

What is happening here is that it’s trying the stringify the AST (tree a) to markdown, parsing that again, (tree b) and checking if both trees are equal. And it looks like for lists-with-code-and-rules they aren’t when only gfm is on (the default).

@itaisteinherz
Copy link

@transitive-bullshit Is this still blocked by anything? I'd be happy to help with getting this landed, and this also blocks sindresorhus/awesome#1394 from getting merged.

@transitive-bullshit
Copy link
Author

@itaisteinherz @wooorm @sindresorhus, this isn't blocked by anything aside from remark being fairly complicated and me not having the time to push it past the finish line.

Feel free to pick up where I left off 💯 😄

@damccorm
Copy link

damccorm commented Feb 22, 2019

@transitive-bullshit FYI, I've been doing some digging here and have at least isolated the issue with the test cases a little bit further. Right now, when lists-with-code-and-rules.json is getting stringified, it produces:

1. bar:
[… we can ignore this stuff ...]
1. foo:

    line 1
    line 2

1. foo:
[… more stuff we can ignore …]

This middle section (line 1\n line 2) should get parsed as a code block, but instead is getting parsed as a paragraph block.

This is different from what's in lists-with-code-and-rules.text which your solution handles correctly and is explicitly denoted as a code block:

1. bar:
[… we can ignore this stuff ...]
1. foo:

   '''
    line 1
    line 2
   '''

1. foo:
[… more stuff we can ignore …]

I haven't figured out what exactly is causing this yet, but wanted to share in case other people are looking at the problem as well.

@wooorm
Copy link
Member

wooorm commented Apr 19, 2020

Superseded by GH-485.

@wooorm wooorm closed this Apr 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Sublists aren't parsed when indented with tabs
4 participants