Skip to content
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

provide symbols in workspace #365

Open
GitMensch opened this issue Sep 3, 2024 · 1 comment
Open

provide symbols in workspace #365

GitMensch opened this issue Sep 3, 2024 · 1 comment

Comments

@GitMensch
Copy link
Contributor

With the current released vsix the "symbols in editor" (starting with @ in the omnibar) works as expected.
But the "symbols in workspace" (starting with # in the omnibar) shows that there are no symbols provided for that yet.

I suggest to include the following:

  • PROGRAM-IDs; FUNCTION-IDs; METHOD-IDs
  • EXTERNAL variable-names, maybe only level 01
  • EXTERNAL file-names
  • from copybooks - possibly later:
    • data-names with 01/77/78 level numbers
    • SECTION names
@GitMensch
Copy link
Contributor Author

No this is not supported yet. This apparently requires some ability to precisely scan a whole workspace, which we anticipate to be a rather costly operation, and therefore needs to be designed with care on the LSP server's side to avoid too many noticeable impact on performance.

Originally posted by @nberth in #377 (comment)

The way to do that (best practice when spgennard added something similar) is to create a command for scanning the whole workspace. This can be executed manually. There should be a configuration to automatically run this once at startup.

The result would be put somewhere (similar as ctags would do it), possibly even one file per workspace file (the file date will be included so that if the file did not changed that db entry is not updated and the LSP does not need to scan it).

If a user opens a file (= the old results from the db can be used directly and then a scan for this background be done - so the general performance for opening big files would also increase) this database is always updated (so even without doing the global scan once the db will increase step by step - as files are opened).

The place to write this database should default to the workspace/extension storage, but be able to be configured for a different place which then also needs to be prepared for multi-user access [huge workspace with one shared db].

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

No branches or pull requests

1 participant