-
-
Notifications
You must be signed in to change notification settings - Fork 124
#284 unconditionally remove leading and trailing lines from code blocks #286
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
base: master
Are you sure you want to change the base?
Conversation
|
@mvdan Can you take a look at this? |
|
ive been using this pr for a while on some projects and it indeed works. =) Thanks @davidmdm |
|
@flan6 I would love this to be merged so that we can get it integrated into gopls. I have to build my own branch of gopls to get the automatic formatting behavior that I want :( |
|
Hi @flan6, I saw it, however I don't have the bandwidth personally to figure out how to do the look ahead to figure out if the block precedes an if-else or else block. Also, personally, I prefer the current behaviour where all blocks are pruned of newlines. These things combined mean that I haven't had the time or motivation to address @mvdan's review. If you're able to carry it through that would be great. Otherwise I'll try and get to it eventually but it won't necessarily be in the next month or so. |
I see, and I agree with you about the rule. But nonetheless it is a great improvement over what it was before. And I am very grateful for your effort so far! Again, thank you so much |
|
Is this PR still relevant? |
|
Personally I would love it if this change were to be seriously considered and adopted. Leading and trailing lines in code blocks are a personal pet peeve. However, if its decided that it is too breaking, or these empty lines are desirable enough in some cases, then I am happy to close or have Dan close it. |
|
If this deletes an empty line after a fn definition it should be disableable. |
This implements as far as I can tell, the change needed for this issue.
Unclear as to how where tests live at this time, but running
go test ./...seems to still be working.