-
-
Notifications
You must be signed in to change notification settings - Fork 68
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
Description retains original indentation. #26
Comments
Unlike DocString, where the indentation has to be consistent or it's an error, there's no constraint on indentation in a description Scenario: Whatever
This
Is
fine
I
believe
Given foo
When bar
Then bam It's not 100% clear what the rule would be for left-trimming the description lines - assume the least-indented one sets a baseline? |
IMO it should ideally error if the subsequent lines don't match the first one, and use that first line as the indent margin for the rest. e.g. Feature: Good indentation
This
is
fine =>
But Feature: Bad indentation
This
is not OK =>
|
IMO both of your representations are valid. I think one of the "bigger" issues at the moment is newlines are being absorbed. So something like
Should look "something like"
Currently it looks like
|
I think we talked IRL but here's an example that I think we'd want to support: Feature: Password hashing
* In 1999 we had a data breach that cost us $4bn
* In 2018 we covered one up by the skin of our teeth
As a consequence we ensure we do not store passwords in plaintext my preference would be a 'trim the smallest indent' also which would result in
And I'd suggest it'd be a good idea to store |
(I also want to be able to do this) Feature: Da Boss
______ _ ___ ___
/ ___(_)__ ________ ____ (_)__ / _ \___ _ / _ )___ ___ ___
/ /__/ / _ `/ __/ _ `/ _ \ / (_-< / // / _ `/ / _ / _ \(_-<(_-<
\___/_/\_,_/_/ \_,_/_//_/ /_/___/ /____/\_,_/ /____/\___/___/___/
|
Note from meeting: Also consider how markdown styling affects sanitization (If it does). EDIT: markdown requires 2 new lines to actually show a new line visually. |
So, regarding the indentation, and indentation only, at the community meeting, we suggest to retain the indentation using HEREDOC rule - we pick the less-indented line and remove that indentation from all the lines - and eventually keeping in the messages the indentation level that has been taken down Any objection into doing that way? If you have some objection, could you explain those and maybe suggest something else? |
@luke-hill I think this is a separate issue: it's purely to do with the choice that we've made in the HTML formatter to use Markdown to render the In order to keep this discussion focussed on the whitespace indentation, let's move that discussion about newlines over to cucumber/react-components#225 |
To throw out some other options, the Behat/Gherkin parser's rule is:
Which I never noticed until today That idea of 'looking at the keyword indent' may be a useful one? |
Although I am a great fusspot about lining things up in source code files, I think being opinionated about 2-space indentation in |
π What did you see?
In reviewing cucumber/react-components#97 it was observed that the description text retains the whitespace indentation from the original feature file.
β What did you expect to see?
Description text should have indentation whitespace removed.
The text was updated successfully, but these errors were encountered: