Skip to content

Conversation

@davidmdm
Copy link

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.

@davidmdm
Copy link
Author

@mvdan Can you take a look at this?

@flan6
Copy link

flan6 commented Jan 17, 2024

ive been using this pr for a while on some projects and it indeed works. =) Thanks @davidmdm

@davidmdm
Copy link
Author

@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 :(

@flan6
Copy link

flan6 commented Apr 1, 2024

@davidmdm hi! have you seen what @mvdan said about this pr on issue #284? I'm not sure if you should do it or me ._.

@davidmdm
Copy link
Author

davidmdm commented Apr 2, 2024

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.

@flan6
Copy link

flan6 commented Apr 4, 2024

Also, personally, I prefer the current behaviour where all blocks are pruned of newlines.

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!
I'll try to carry it on and achieve what mdvan requested and i will surely let you know about the outcome!

Again, thank you so much

@LarsArtmann
Copy link

Is this PR still relevant?

@davidmdm
Copy link
Author

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.

@sitano
Copy link

sitano commented Nov 17, 2025

If this deletes an empty line after a fn definition it should be disableable.

fn f() (
blah) {

// line above should not be deleted if we didn't ask for it
...
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants