Vim integration

[stapelberg]

No description provided.

[fatih]

Hi @stapelberg,

Thanks for the tool, this looks great! I really love this tool and was going to work on a similar one, however now that you wrote it there is no need for me (Which is great!).

Can you please update your Readme to include instructions how it's used inside an editor? Does it accept an offset? What does it return? Does it output in JSON?

As an example please check out this section from gomodifgtags: https://github.com/fatih/gomodifytags#editor-integration As you see the tool provides all the necessary primivites so other editors can easily integrate it. Especially a JSON output is crucial for some editors as it's more efficient because we can just replace the necessary lines with it.

I'm more than happy to integrate but first I need all the information available (above questions on how to use it) so we can integrate this into vim-go.

[stapelberg]

Hey @fatih, thanks for your message!

Currently, the tool accepts a guru-like byte offset into the file, e.g. “myfile.go:#90”. I think that matches gomodifytags’s -offset. See also expanderr_test.go for some examples.

expanderr’s output is the entire file contents, with the specified call expression expanded — this was the most convenient for Emacs integration.

We can totally introduce the JSON output format which you use in gomodifytags. Would you be interested in sending a PR? If not, I can work on it (most likely tomorrow).

[wayneashleyberry]

This is making me so happy right now 😄

[stapelberg]

I took your silence as “too busy right now” and went ahead creating pull request #3. If that looks good to you, I’ll merge it and you can add support in vim-go…?

[fatih]

Thanks @stapelberg. Sorry for the late response, I'm quite busy handling the issues on vim-go and my official work. I've opened this fatih/vim-go#1445 so it's known by us (vim-go). I'll add comments to your PR once I've tried it out.

[fatih]

I've just looked into this and think this needs some improvements until it's ready. Some of the things are:

• For example suppose you have this code:

func foo() error {
	bar()

	// no return yet as I'm still developting this
}

func bar() error {
	return errors.New("foo")
}

When I put my cursor on top of bar() and call :GoExpandErr it returns an error saying:

2017/12/28 17:58:43 ignoring type-checking error: demo.go:54:1: missing return
{"start":51,"end":51,"lines":["\tif err := bar(); err != nil {","\t\treturn err","\t}"]}

It actually returns something. However this is wrong. The error should be part of json and we should be able to decide whether we can change the buffer or not. I think the error message above can be mitigated, but not sure how expanderr implemented it.

• Suppose you have this piece of code:

func foo() {
	// I want to panic here
	bar()

}

func bar() error {
	return errors.New("foo")
}

When I call :GoExpandErr when my cursor is on bar()~ inside foo()` I got this error:

2017/12/28 18:04:49 current function returns no values, cannot return error

I think if there are no returns, it should default to panic(err.Error()) or something alike.

[stapelberg]

I created issue #14 and #15 to track these suggestions. Help welcome.