Skip to content

GoReferrers sometimes show raw text (not a link) with nvim #1836

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

Closed
LopatkinEvgeniy opened this issue May 22, 2018 · 5 comments
Closed

GoReferrers sometimes show raw text (not a link) with nvim #1836

LopatkinEvgeniy opened this issue May 22, 2018 · 5 comments

Comments

@LopatkinEvgeniy
Copy link

LopatkinEvgeniy commented May 22, 2018

What did you do? (required. The issue will be closed when not provided.)

type :GoReferrers

What did you expect to happen?

List with links to the code where current variable used.

What happened instead?

Some rows are not links, they are just text. See third row.
screenshot from 2018-05-22 21-38-09

Configuration (MUST fill this out):

  • vim-go version:
    1.17

  • vimrc you used to reproduce (use a minimal vimrc with other plugins disabled; do not link to a 2,000 line vimrc):

call plug#begin('~/.config/nvim/plugged')
Plug 'fatih/vim-go', { 'do': ':GoUpdateBinaries' }
call plug#end()
  • Vim version (first three lines from :version):
    NVIM v0.2.2

  • Go version (go version):
    go1.10.1 linux/amd64

  • Go environment (go env):

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/evgen/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/evgen/go"
GORACE=""
GOROOT="/usr/lib/go-1.10"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.10/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build845585396=/tmp/go-build -gno-record-gcc-switches"
@arp242
Copy link
Contributor

arp242 commented May 25, 2018

What do you mean with "sometimes"? Only in some cases (and running it the second time will work fine)? Or only with some code?

A reproducible example would be very beneficial.

@LopatkinEvgeniy
Copy link
Author

It reproduces often in various projects. There is no specific case to reproduce. You may reproduce it with "centrifugo" repo, like in my screenshort. https://github.com/centrifugal/centrifugo.

@bhcleek
Copy link
Collaborator

bhcleek commented May 30, 2018

@LopatkinEvgeniy I can duplicate what you're seeing, but only in Neovim; Vim8 works fine.

@bhcleek bhcleek added the bug label May 30, 2018
@bhcleek
Copy link
Collaborator

bhcleek commented May 30, 2018

This appears to be a bug in Neovim; it's not honoring the stdout_buffered setting correctly. Instead, some lines appear to be just as they were if stdout_buffered was not set. I'll see if I can workaround the what Neovim is doing.

@bhcleek
Copy link
Collaborator

bhcleek commented May 30, 2018

Upon closer inspection, it's not clear if there's a bug in Neovim or whether Neovim docs are just unclear.

Either way, it appears that the best solution is to make sure guru is always called with the -json flag and to make sure that when s:job_start in autoload/go/guru.vim joins all the output lines with with an empty string instead of with \n.

Making the change to always call guru with -json is bigger than what I have time to do right now, but I'll try to get to it in the near term.

bhcleek added a commit to bhcleek/vim-go that referenced this issue May 30, 2018
Output from a Neovim job may come in batches and splits on newlines.
When the output ends with a newline, the last element in the data passed
to the stdout and stderr callbacks will be the empty string. When it's
not the empty string, then last element is an incomplete line, and the
next call will contain the rest of the line in the first element of its
data.

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

No branches or pull requests

3 participants