You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When multiple-empty-lines is enabled (especially together with new-line-at-eof) and the problem happens @ the final lines of the file, it seems that the reported line falls out from the number of lines in the file
While that's not a huge problem... the reported line should be, always an existing one. Without that, systems that filter checks against the modified lines in a patch skip that error.
So, for example, this simple feature:
Feature: Confirm gherkinlint reports the problem within existing lines
Scenario: Trailing file blank
Given this
When that
Then yes
<blank_line_goes_here, just a \n>
Reports:
7 Multiple empty lines are not allowed no-multiple-empty-lines
When that file has, at all effects, only 6 lines (editor, diff, everybody says lines are 1-6)
The text was updated successfully, but these errors were encountered:
Hey @stronk7 , I can't reproduce the issue on my end.
I copied the example you mentioned
and the errors I got corresponded to the file lines
In the code you linked we're reporting the error on i + 2 instead of i + 1 to convert 0 index line numbers to 1 index (I will add a comment in the code about that, because it took me a while to remember).
Do you mind letting me know which verison of node and what OS you're using so i can try to reproduce it in an environment more similar to yours?
Hi @vsiakka, when I detected this we may be using lts/carbon. Since then we have upgraded to v14.0.0 and can reproduce the problem easily. Also, I'm a Mac, but don't think it's a factor at all.
The file is nothing strange, just a standard LF ended file having SIX lines, the last one being a blank one.
Compressed original: 226.feature.gz
Run the linter.
It reports 7 Multiple empty lines are not allowed no-multiple-empty-lines when clearly there isn't a 7th line. The 6th one should be reported.
When multiple-empty-lines is enabled (especially together with new-line-at-eof) and the problem happens @ the final lines of the file, it seems that the reported line falls out from the number of lines in the file
While that's not a huge problem... the reported line should be, always an existing one. Without that, systems that filter checks against the modified lines in a patch skip that error.
So, for example, this simple feature:
Reports:
When that file has, at all effects, only 6 lines (editor, diff, everybody says lines are 1-6)
The text was updated successfully, but these errors were encountered: