tool: LSP support

[bung87]

Summary

• LSP support

Details

---

Notes for Reviewers

• get some improvements idea in my mind but first release initial version

[saem]

can you drop the nimble and nims files, plus any unnecessary cfg files.

[bung87]

can you drop the nimble and nims files, plus any unnecessary cfg files.

sure, as this will stay with main repository.

[saem]

it'll probably be easier for reviewing to avoid force push -- all the squashing is taken care of during merge.

[zerbina]

For the directory structure, I think nimlsp.nim should move besides nimsuggest.nim in the tools directory, with the nimlsppkg directory (which can then be renamed to just nimlsp) also moved to tools.

In addition, please:

• move the outline command implementation changes into a separate PR
• remove the nimsuggest.nim copy -- the changes necessary for the LSP should be merged into the existing module

[bung87]

• outline is part of nimsuggest lib, not belongs to old nimsuggest.nim
• LSP (Language Server Protocol) Replacement for Nimsuggest #448 isn't the plan is drop nimsuggest? also nimlsp don't handle other protocol and command flags and do the tester.nim's work.

[zerbina]

Yep, the plan is to remove the custom nimsuggest protocol, and with that, nimsuggest itself.

Until that's done, nimsuggest has to keep working. Having a largely duplicate version of nimsuggest is a problem, since it means that potential fixes/changes need to be applied to both modules.

What I'm suggesting/requesting is the following:

• nimsuggest.nim keeps implementing the nimsuggest server, as it does now
• the module also exports the parts needed by the LSP
• the LSP server (nimlsp.nim) imports the existing nimsuggest.nim
• once the LSP server is able to fully replace nimsuggest.nim, the latter is merged into the LSP server's code or restructured

• outline is part of nimsuggest lib, not belongs to old nimsuggest.nim

I'm not sure what you mean. The outlining implementation is not part of nimsuggest itself, yes, but the feature is still integrated into nimsuggest. In addition, moving to a parser-based implementation is independent from introducing LSP support, hence my request to split it into a separate PR.

Keeping PRs focused on a single area or feature helps with reviewing them, and writing commit messages is usually also easier when the PR is smaller.

[zerbina]

@bung87: Please stop force-pushing, thank you. As Saem said, it unnecessarily makes review harder.

In addition, if the PR is not finished, please turn it into a draft PR. Each push to a PR that is marked as "ready for review" will trigger a run of the CI, which adds unnecessary resource contention.

[bung87]

guess I'll create another PR

[saem]

partial review