-
-
Notifications
You must be signed in to change notification settings - Fork 28
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
Preserving comment-only lines? #16
Comments
Yeah, a is the expected behaviour. |
I'll try and fix this. |
This seems to be the bug. Herein lies the ambiguity: What part of the code do the comments belong to? The line of code below the comment? The one above? Something else entirely? It is certainly fixable, but we should define a clear answer for this. |
Possible convention:
Examples: [test]
# this comment belongs to the line below
x = 10
y = 20
# this comment belongs to the line above
# this comment also belongs to the line above
# this comment belongs to the line below
z = 30
# this comment belongs to the line below
w = 40
# this comment belongs to the line above |
I think all comments up to a key belong to that key. However, comments that don't have any key after them (comments at the end of file) should be kept. |
@gaborbernat what about this: [options.entry_points]
# some comment about the project in general
b = 20
a = 10 when you sort the entry points, you don't want the top level comment to be dragged with |
I don't agree, I think it should be dragged 🤔if one wants generic comments could be before the table |
is this the desired outcome? (whitespace being removed as well) [options.entry_points]
a = 10
# some comment about the project in general
b = 20 |
More like: [options.entry_points]
a = 10 # some comment about the project in general
b = 20 If fits in one line, otherwise: [options.entry_points]
# some comment about the project in general
a = 10
b = 20 I can see an argument for putting comments after the key it belongs to too. Need to have a think. One of those two. Generally, whitespace should be collapsed IMHO. |
I see, that makes sense. Something got misunderstood before. When you say "all comments up to a key belong to that key", in this case: [foo]
# bar
x = 10
y = 20 that would mean Which I believe is what you're thinking of as well. |
@gaborbernat honestly i don't think I'd be able to get back to this. i have an unfinished PR as a starting point if someone wants to take it up. |
Hi there. Apologies if it might be unrelated, but at least it is also about preserving comments or not, and how, so I wanted to reference this other occurrance where pyproject-fmt is tripping us a bit. Nothing serious though, thanks for your great work! |
I hit the exact same issue as @amotl . I'm happy to make a new issue if preferred. What I want: [project.optional-dependencies]
dev = [
"check-manifest",
# Comment about why we pin doc8 to this version
"doc8==0.11.2",
] The comment is associated with |
FYI, I've been playing around to moving the project to use the taplo https://taplo.tamasfe.dev AST parser and formatter that would allow this - https://github.com/gaborbernat/pyproject-fmt-rust; will likely take another few weeks for this to happen but help there is welcome. |
@gaborbernat do we need an issue to track where the migration stands in terms of feature parity? |
The test suite itself is the tracker. Currently, if you check, the CI is failing as there's no feature parity. |
Awesome! Thank you for doing this! |
Currently this project only preserves comments when they're on a line with syntax, otherwise they are removed:
pyproject.toml
:Seems like it would make sense to either:
My personal opinion is that a) would be ideal!
The text was updated successfully, but these errors were encountered: