Currently, the minimap has a fatal bug. The problem is that the entire Goneovim application will randomly freeze if you continue to operate the application while the minimap is displayed.
450 is a related issue.
I am investigating this issue but do not know the root cause.
The results of the analysis by go-delve show that the values are not received in the channels created inside neovim/go-client and remain in a waiting state. This can be understood as no response from Neovim as a result of executing the API to Neovim.
On the other hand, if it freezes, it is likely that there is a more fundamental problem hiding behind it, since it occurs in the same processing each time.
Frame 3: /Users/akiyoshi/goneovim/vendor/github.com/neovim/go-client/msgpack/rpc/rpc.go:299 (PC: 5b19198)
294: return nil
295: }
296:
297: // Call invokes the target method and waits for a response.
298: func (e *Endpoint) Call(method string, reply interface{}, args ...interface{}) error {
=> 299: c := <-e.Go(method, make(chan *Call, 1), reply, args...).Done
300: return c.Err
301: }
302:
303: // Go append method call to queue and returns the new Call.
304: func (e *Endpoint) Go(method string, done chan *Call, reply interface{}, args ...interface{}) *Call {
(dlv) print
Currently, the minimap has a fatal bug. The problem is that the entire Goneovim application will randomly freeze if you continue to operate the application while the minimap is displayed.
450 is a related issue.
I am investigating this issue but do not know the root cause. The results of the analysis by go-delve show that the values are not received in the channels created inside neovim/go-client and remain in a waiting state. This can be understood as no response from Neovim as a result of executing the API to Neovim. On the other hand, if it freezes, it is likely that there is a more fundamental problem hiding behind it, since it occurs in the same processing each time.