Skip to content
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

current editing file lost after :GoRun output error text #287

Closed
wheelcomplex opened this issue Jan 15, 2015 · 3 comments · Fixed by #547
Closed

current editing file lost after :GoRun output error text #287

wheelcomplex opened this issue Jan 15, 2015 · 3 comments · Fixed by #547
Labels

Comments

@wheelcomplex
Copy link

this is a sample:

package main

func main() {
println("read 0 byte, err read tcp 127.0.0.1:8800: i/o timeout: []")
}

@fatih fatih added the bug label Jan 19, 2015
@fatih
Copy link
Owner

fatih commented Jan 19, 2015

It's because of makeprg. If you run GoRun it changes makeprg and executes make inside Vim. This runs the go run command and parses the output. The text read 0 byte, err read tcp 127.0.0.1:8800: i/o timeout: [] is seen as an error line, so makeprg automatically parses it and puts into the quickfix list. If you change the print message it'll will go away. The make command doesn't return the exit status, so I can't distinguish between a successful or failed GoRun. If you remove the column characters : it will go away. Unfortunately there is no easy way to fix it right now.

@fatih fatih closed this as completed Jan 19, 2015
@wheelcomplex
Copy link
Author

thank you very much, let's wait for

@athuth
Copy link
Contributor

athuth commented Sep 22, 2015

I think I've run into this bug while using log.Logger to print to stdout. When using either log.Lshortfile or log.Llongfile, a colon is automatically inserted. Only if I forego those flags (making the logger significantly less useful) can I prevent GoRun clearing the window.

I forked your repo to study the problem, starting by documenting the errorformat patterns used in go.vim. They seem pretty aggressive, is it really that hard to restrict the patterns so they don't catch, e.g., TRACE or WARNING lines?

(UPDATE)

Okay, so the whole start of the line is being parsed as %f, and cc 1 (as on line 89 of cmd.vim) tries to open that file name. So in OP's sample, a new file is opened named read 0 byte, err read tcp 127.0.0.1. Maybe it's possible to validate %f against known files and suppress the item from showing in the quickfix window if it can't figure out what file to jump to?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants