Large amount of *gocode* buffers when company-go--invoke-autocomplete has an error

[bmag]

In company-go--invoke-autocomplete, if call-process-region encounters an error then the temporary *gocode* buffer isn't killed, resulting in many *gocode* temporary buffers accumulating in the background. It seems that using with-temp-buffer instead of generate-new-buffer or condition-case instead of prog2 (and suitable refactoring) should fix this.

Original report: syl20bnr/spacemacs#7979

[nsf]

The question is - why. Script has kill-buffer at the end there. And it worked well for years. What changed?

[bmag]

In the particular case reported to Spacemacs, the user didn't have a necessary program installed, causing an (expected) error in the call to apply. It seems to me the code doesn't have any error handling.

[nsf]

Makes sense. Will try using with-temp-buffer then.

[nsf]

I think I fixed it, but please take a look at the code. I'm not very good with elisp. Also maybe there is a simpler way to do it? It's just a bit messy. I need to get args from current buffer, stuff like cursor position, then I need to create a temporary buffer and get its name for call-process-region destination, then I switch to the code buffer (because call-process-region uses its contents), but I had to remember its name before that. And I return the contents of the temporary buffer. Looks like a giant mess. Cleanup patches are welcome.

[bmag]

I looked at it, I'm not sure there's a cleaner way to write the code with with-temp-buffer. However, we can replace prog2 with unwind-protect (I know I mentioned condition-case earlier, but that's because I forgot about unwind-protect):

(unwind-protect
    (progn
      (apply #'call-process-region
             (point-min)
             (point-max)
             company-go-gocode-command
             nil
             temp-buffer
             nil
             gocode-args)
      (with-current-buffer temp-buffer (buffer-string)))
  (kill-buffer temp-buffer))

What this code does, is that it calls kill-buffer even if there's an error inside the progn.

[nsf]

Well, ok, let's keep it this way then, feel free to close the issue if with-temp-buffer one works for you.

[bmag]

I'm closing the issue because I'm fairly certain the issue is solved. I haven't actually test it because I wasan't affected by it. @InvisibleTech @rbrtl @nyxwulf if you can confirm this works it'd be nice (this only fixes the *gocode* buffers, not the *go-eldoc* buffers)