Use specified line endings in multiline comments. #550
Conversation
Allow comments in selective imports. (dlang-community#403)
There was a problem hiding this comment.
not sure if the tests folder is the right place for this, as git may change the line endings on different OSes or settings.
Note: the reason for this issue is that the comment tokens coming from libdparse are pasted as-is (tokens are never modified in dfmt) which is why the LF is kept in a CRLF file.
You would need to add replace code when outputting comments and strings (which will exhibit the same behavior) to fix this issue.
Good point. I'll remove the files from the repository and generate them instead.
I think https://github.com/dlang-community/dfmt/pull/550/files#diff-f5d86cddb20837cd3a9f154e16b9a929d7b7d133ce71a5022127e5ec30d94a00 does the right thing.
|
I take that back. It currently is LF by default, see #552. |
Multi-line tokens would be written with `lf`, regardless the `end_of_line` setting. Fixes dlang-community#228.
If everything works as advertised, this shouldn't be happening courtesy I had to rewrite this slightly to work properly for all kinds of line endings in the input. |
| output.put(current.text.replace("\r", "")); | ||
| else | ||
| output.put(current.text); | ||
| output.put(current.text.lineSplitter.joiner(eolString)); |
There was a problem hiding this comment.
For a moment I thought this would omit the trailing newline. But dfmt always ends the output with a newline even if the input doesn't, so it's good. #551 will detect if this ever changes.
There was a problem hiding this comment.
instead of doing the short and easy, but memory intensive way, how about adding a helper function that first checks if there are non-conforming line-endings and then runs the lineSplitter + appends it all on it?
There was a problem hiding this comment.
nvm I just realized these are ranges and should be fine as is
|
Thanks. |
fix #228