Return full symbol name for documentation lookup

[nikclayton]

I've been looking in to getting company-quickhelp working with Emacs / gocode / company-mode.

tl;dr: It doesn't work properly, because the output from gocode only includes the completion candidate, not the full context necessary to look up documentation. E.g., if I've typed "fmt.Spri", the completion candidate information is "Sprint", "Sprintf", "Sprintln", without the leading "fmt.". Without the package name, "go doc" doesn't find anything.

It does work for stuff that's within the same package though, which is something.

So it would be very helpful if the output from gocode included a field that could be reliably passed to "go doc".

Here's how to replicate what I've done so far.

Install gocode, company, and company-quickhelp (https://github.com/expez/company-quickhelp).

company-quickhelp / company interact with the doc-buffer command passed to the company backend. company-go. This command should respond with a buffer that contains the help documentation.

gocode/emacs-company/company-go.el doesn't do that yet, so edit company-go.el as follows:

(defun company-go (command &optional arg &rest ignored)
  (cl-case command
    ;; ...
    (doc-buffer
      ;; arg is a string corresponding to the user's completion selection.
      (godoc-as-buffer arg))
    ;; ...
  ...)

(defun godoc-as-buffer (query)
  "Return Go documentation for QUERY as a buffer."
  (unless (string= query "")
    (let ((buf (godoc--get-buffer query)))
      (call-process-shell-command (concat godoc-command " " query) nil buf nil)
      buf)))

Eval both of those, open a .go file with go-mode, company and company-quickhelp enabled, and try some autocompletion in it.

If you leave an item in the menu of completion items that pops up selected for a second or so you should see a documentation popup appear. If it's something that "go doc" can find (e.g., a function in the same package that's got documentation) you should see the item's documentation. But if it's in another package "go doc" can't find it, so you get "doc: No symbol foo in package" as the documentation.

If gocode included a new field in the output that contained the full package name company-go.el could add that as a property that would be accessible within the doc-buffer command.

[nsf]

Yes, I understand the problem, but not sure when I'll be able to do something about it. Lack of motivation.

[zchee]

@nsf Now I'm planned try the solve another issue that related stdlib package import, and the adjust candidates result when "import C".

Is

"Lack of motivation."

means like "would be great if possible, but I haven't motivation" ? (sorry that is "English" question...)
If so, I will try to implement this feature together. but If it means "it seems to be excessive for gocode", I'll follow your decision.

---

BTW, as I said, I want to fix stdlib package import and adjust candidates result when "import C". But it might be you do not like. Can I create issue thread for it?

[nsf]

"Lack of motivation" means I have no desire to work on gocode right now. In particular, adding new features. I've said a few times, I'm in "maintenance only" mode for gocode and frankly all of my open source projects. If gocode stops working after some Go version release, I'll fix it, but anything beyond that is postponed for indefinite period.

[zchee]

@nsf Ah, okay. I understand. I will not implement that.

BTW,

I want to fix stdlib package import and adjust candidates result when "import C".

That is, Now gocode can complete non-imported stdlib methods, but IIRC doesn't support duplicated pkg name such as text/template and html/template(right? or already solve it?) I want to return the correct method candidates.

Another one, import "C"'s nit issue. When imported some package that uses cgo, IIRC candidates result args is included _C***_ method prefix on type section. such as Foo(when dispatch._Ctype_dispatch_time_t) (If pkgname is dispatch). It would be replaced when the compile time for that pkg with cgo. So, I want just simply trim the first underscore, or replace to any prefix (if you like it) In this case, dispatch._Ctype_dispatch_time_t to...

• dispatch.Ctype_dispatch_time_t or
• dispatch.C_dispatch_time_t or
• dispatch.C.dispatch_time_t

It's very nit issue, and already readable. But also might be this change is low-overhead. (I wondered whether to propose this)

Do you think both cases are "adding new features" ? Also, What do you think about this change?

---

@nikclayton Sorry for using you created issue thread.

[nsf]

I don't mind if somebody adds a new feature, what I'm saying is that I won't be doing so. I have no optinion on cgo-related issues as I haven't used cgo for quite some time.

[zchee]

@nsf Ah, Now totally understand all your thought. Sorry. I want to those, will start those fix and send a pull request.

Also, I do not know if you are consent about the next language specification, but I'm started implement "type alias" new language spec support. I will send a pull request after being merged from dev.typealias branch to master (if I can make it in time and have backward compatibility)