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

Project management #598

Merged
merged 27 commits into from
Jul 7, 2020
Merged

Conversation

nickspoons
Copy link
Member

@nickspoons nickspoons commented Jun 18, 2020

This PR is where I'm tracking modifications to project management. Done so far:

  • Refactor project listening into new autoload script
  • Maintain a list of projects which have been loaded for the solution (when a solution exists)

The list of projects can be used to display "server loading progress" in the statusline - here's an example using vim-sharpenup, PR#4:

project_listener

Things I hope to achieve here:

  • Detect whether the server is the OmniSharp-rolsyn HTTP server when stdio was expected, so we can warn the user, then change mode. This will allow us to make stdio the default in a backwards-compatible way.
    Update: I looked into restarting the server in HTTP mode, but it requires too many changes for little gain. The entire session is set up either for HTTP or stdio including autocmds for linting engines and compatibility checks. Detecting the wrong server and stopping it cleanly with a warning message is fine.
  • Improve the load system so that highlighting/completion etc. become available as soon as the current project is loaded. Diagnostics will still warn of unloaded references, and definitions in unloaded projects will not be available until those projects are loaded etc.

Note: the final point hopefully encompasses a fix for #599 Update: it does not, #599 is a WSL bug and will be fixed on the OmniSharp-roslyn side.

Closes #468

Update: Since looking into the project loading mechanisms involves heavy use of the logs, I have included some other updates here that make this a bit more manageable:

  • Give each OmniSharp-roslyn session its own log file. This means that a single vim session may be writing to multiple logs, if it is running multiple sessions. The old "stdio.log" file is still used as a global catchall - the filename of each session log is added to it, so it is possible to gf into actual log files from there.
  • Format the log in a similar way to the VSCode formatting, making it actually readable - the raw JSON is extremely difficult to find relevant information in.
  • Add new filetype and syntax for the logs, including folding raw requests/responses (when logging at debug level).

omnisharplog

@nickspoons
Copy link
Member Author

Status update: 4f2e069 is a very different approach to project loading, and works really well - highlighting, for example, is available very quickly, and no errors are received from the server. Request-replaying also works much better, as pending requests are saved per-buffer, instead of per-command, meaning that 2 buffers can have pending highlighting requests replayed as soon as their buffers are initialised.

However there are some diagnostic timeouts happening on the server which I believe are new, and diagnostics appear to take longer now than before. So I'll look into this before merging.

The OmniSharp-roslyn loading issues appear to stem from situations where
multiple buffer-requests are sent before the project is fully
initialized. This results in duplicate "miscellaneous" files, which are
not correctly promoted to "project" files.

Instead, this commit introduces a buffer "initialization" concept, where
an `/updatebuffer` request is always sent as the first request for a
buffer, and no further requests are sent for that buffer until a
response is received (indicating that the server has registered the
file, and there will be no duplicates created).
Highlighting can work well as soon as the buffer is initialised (well
before the project is loaded). However, some aspects of highlighting are
project-dependent (e.g. pre-processors depending on project
configuration), so the _correct_ highlighting will only be applied after
the project has loaded completely.
@nickspoons nickspoons changed the title WIP: Project management Project management Jul 7, 2020
@nickspoons nickspoons merged commit a7ea2dc into OmniSharp:master Jul 7, 2020
@nickspoons nickspoons deleted the project-management branch July 7, 2020 03:25
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

Successfully merging this pull request may close these issues.

Feedback wanted! stdio
1 participant