AndrewRadev/splitjoin.vim

Go: split of multiline var, const adds brackets in wrong place

ArtAndreev opened this issue · 2 comments

First of all, thanks for your work and support for go! I used it for several months and noticed some little issues. Looks like, the following cases were missed in #201 or #202.

For example,

package main

var first = map[string]any{
	"k": "v",
}
// split results to:
// var (
//	first = map[string]any{
//	)
//	"k": "v",
// }

var ( // Expected this, but this cannot be joined.
	second = map[string]any{
		"k": "v",
	}
)

var third = 0 // split is ok.

var ( // join is ok.
	fourth = 0
)

type fifth struct{} // cannot be splitted

// expected:
type ( // join is ok, btw.
	sixth struct{}
)

The problem with this example is that it's already multiline:

var first = map[string]any{
	"k": "v",
}

What I would do in this case is f{, then join, then 0 to go to the first column, and split. I get this result:

var (
	first = map[string]any{ "k": "v", }
)

The comm at the end of the dictionary is a bit weird in this case, I'm not sure why it's not being removed. I don't know what gofmt would think about it, since I don't have go on this machine, but I might debug this at a later time. You could also jf{ now to be able to split the struct again.

I've added some logic to at least avoid doing the wrong thing if someone tries to split. I know it's not ideal, but if I added something like "automatically jump to the bracket and join before splitting", that would add a lot of complexity -- what happens if it the split doesn't work and I have to undo it, for instance? It's tricky.

type fifth struct{} // cannot be splitted

It's weird, I had a special case to avoid splitting that. I don't remember why 😅. It might have been to fix some specific case, but I don't seem to have a test for it. If you see a regression elsewhere, let me know. I've removed the special case, so this should work now.

Understood with multiline single-var block. Let it stay as it is now.

Btw, a trailing comma is stripped by gofmt, no real problem with it.

Empty struct splitting works just as fine as other cases, thanks!