@macintacos Thanks for the report. Can. you please share your settings?
In particular, I want to know whether you are using the language server or not ("go.useLanguageServer": true).

Here are all my go-related settings (go.useLanguageServer is set to true):

  "[go.mod]": {
    "editor.codeActionsOnSave": {
      "source.organizeImports": true
    },
    "editor.formatOnSave": true
  },
  "[go]": {
    "editor.codeActionsOnSave": {
      "source.organizeImports": true
    },
  },
  "go.autocompleteUnimportedPackages": true,
  "go.buildOnSave": "package",
  "go.formatTool": "goimports",
  "go.lintFlags": ["--fast"],
  "go.lintOnSave": "package",
  "go.lintTool": "golangci-lint",
  "go.useCodeSnippetsOnFunctionSuggest": true,
  "go.useCodeSnippetsOnFunctionSuggestWithoutType": true,
  "go.useLanguageServer": true,
  "go.vetOnSave": "package",

There is a stack of changes to improve the workspace symbol support in progress: https://go-review.googlesource.com/c/tools/+/228760/31. This work needs to be rebased but will then hopefully form the basis of more advanced search modes, including better ranking (I experimented with an advanced query syntax in https://go-review.googlesource.com/c/tools/+/227677/41)

cc @findleyr

Awesome, thanks @myitcv! I'll follow along.

Change https://golang.org/cl/247818 mentions this issue: internal/lsp: refactor workspace Symbol method

The above CL (based on Paul's original CL) improves ranking for fuzzy matching, and prepares for further ranking improvements.

I jump to symbols outside of my workspace all the time, so would object to removing that feature altogether :) Let's start by downranking symbols outside of the workspace and see if that is good enough -- I'd like to avoid adding another configuration option if possible. Regarding "preferably an option between either because why not": because it takes effort to support!

Also, regarding this

It doesn't seem to populate results immediately (for me). The prompt comes up and it doesn't give me a list of variables immediately without needing to type in a search

@macintacos what would you like to see without a search query? In any moderately sized project there will be so many symbols that whatever arbitrary N symbols are returned for the empty query are unlikely to be relevant. We're also limited by the LSP in what we can do here: we don't know which buffer(s) are currently visible in the editor, so we can't do something like prefer symbols in the current file. We could do something, like show recently used symbols or symbols in open files, but I'm not convinced either of those are worth implementing. In practice, the user will almost always type something.

CC @heschik

Change https://golang.org/cl/248383 mentions this issue: internal/lsp/source: add some downranking for workspace symbols

@findleyr Fair enough on all the initial points!

As for what to show without a search query, showing the most recently used symbols in open files makes sense to me, but I understand the motivation to leave it the way it is. I use VSCode for Python as well, so perhaps that's a good point of reference, considering that it's such a widely used extension? From what I can tell, it just lists symbols in the project in alphabetical order, but I'm not sure of their motivation behind doing it that way. The only thing I can think of is that it's reassuring to see some visual feedback that the extension knows about symbols in your project before you begin typing, so showing symbols alphabetically is "good enough".

I don't have any strong opinion about showing symbols before you begin typing though; that has less of an impact in relation to the ranking behind the search itself.

Change https://golang.org/cl/254037 mentions this issue: internal/lsp/source: add some additional symbol downranking

With the combination of dynamic symbols becoming the default, and the downranking that was added, I think the situation is significantly better now. Going to close this as I have no other concrete ideas for what to improve. Please re-open if workspace symbol ranking is not working for you.

The only thing I would like to see being added is, as we discussed previously, some means of predefining the scope of a search. I find myself regularly wanting to jump to an identifier within the current package (where "current" is defined by the file in which the cursor was sitting when the command was triggered) - having the search space be "everything" means:

• it's slower
• it's more typing to get to the precise answer

But I'll raise this in a separate issue, and/or implement if I find some time.