Load current repl window namespace

[PEZ]

So, two for one in this PR. Just because they go a bit together....

Load current repl window namespace

Make the Load Current File command work in the repl/output window, but then load the current namespace instead.

Fixes: #910

Special colon symbols and hard space in the prompt

I find myself wanting to have easy access to the namespaces shown by the prompt in the output window. This change replaces the regular : (colon) characters with some unicode version I found that looks the same. Then I could change the grammar some to not treat this as part of symbols.

This makes the ns in the prompt a peekable symbol and also allows for navigating to it.

I also replaced the space with a hard space, hoping that that Trailing Space extension will not warn about it.

Fixes #808

My Calva PR Checklist

I have:

• Read How to Contribute.
• Directed this pull request at the dev branch. (Or have specific reasons to target some other branch.)
• Made sure I have changed the default PR base branch, so that it is not master. (Sorry for the nagging.)
• Updated the [Unreleased] entry in CHANGELOG.md, linking the issue(s) that the PR is addressing.
• Figured if anything about the fix warrants tests on Mac/Linux/Windows/Remote/Whatever, and either tested it there if so, or mentioned it in the PR.
• Tested the VSIX built from the PR (so, after you've submitted the PR). You'll find the artifacts by clicking Show all checks in the CI section of the PR page, and then Details on the ci/circleci: build test. NB: There is a CircleCI bug that makes the Artifacts hard to find. Please see this issue for workarounds.
  • Tested the particular change
  • Figured if the change might have some side effects and tested those as well.
  • Smoke tested the extension as such.
• Referenced the issue I am fixing/addressing in a commit message for the pull request.
  • If I am fixing the issue, I have used GitHub's fixes/closes syntax
• Created the issue I am fixing/addressing, if it was not present.
• Added to or updated docs in this branch, if appropriate

The Calva Team PR Checklist:

Before merging we (at least one of us) have:

• Made sure the PR is directed at the dev branch (unless reasons).
• Figured if anything about the fix warrants tests on Mac/Linux/Windows/Remote/Whatever, and tested it there if so.
• Read the source changes.
• Given feedback and guidance on source changes, if needed. (Please consider noting extra nice stuff as well.)
• Tested the VSIX built from the PR (well, if this is a PR that changes the source code.)
  • Tested the particular change
  • Figured if the change might have some side effects and tested those as well.
  • Smoke tested the extension as such.
• If need be, had a chat within the team about particular changes.

Ping @PEZ, @kstehn, @cfehse, @bpringe

[PEZ]

Marking this as ready for review, @bpringe , even though I do think I need to go over the changes some before I think they are ready to go. But if you find some time for it, please have a look. One of the things you might want to look at is that I remove the jar TextDocumentProvider that the lsp module added. Since we already have such a provider, which I reuse for the load namespace command.

[bpringe]

I'll have to try out / review the rest of it later, but I'm not sure if we should get rid of the clojure-lsp jar content provider. I spent a while fixing it for Windows recently in clojure-lsp, and with the code in this PR, when I try to navigate into a jar dependency on Windows it fails (just a blank file with a progress indicator that doesn't stop).

The clojure-lsp jar content provider (via that dependencyContents request we make), works for Windows. Maybe if we fix Calva's to work for Windows it would be fine, but I also don't see an issue with only using clojure-lsp's jar content provider, especially since we know it's cross-platform now.

[PEZ]

Yes, we could use either or. It is mainly using both that I don't like. I considered using the one in the lsp module, but it had a dependency on the lsp client, and it was late here. I'll have a look.

[PEZ]

Trying the dev branch on Windows, I don't get any definitions for core or library symbols. In fact there is no a call to our jar content provider. So there is something else going on. And it makes it hard to fix the problem you see of course, since I never get there. I'll make it work on Mac (and probably on Linux) and we make it work on Windows later. Our own jar provider is tried and tested over many years, so I'll go for that one for now.

[bpringe]

About to try this out now!

[bpringe]

In fact there is no a call to our jar content provider. So there is something else going on.

FYI, I think there is some caching business that occurs with the content provider. If you don't see a breakpoint in the provider being hit, restart the extension development host and then try it again. I've noticed I have to do that, but after the contents are provided once, the feature works without going into the provider code again.

[bpringe]

Ok I have some insights about the jar content loading on Windows. What I know so far:

• Until clojure-lsp finishes starting, using Go to Definition on a jar dep says "No definition found"
• Once clojure-lsp starts, execution goes through the provideDefinition middleware and since no repl is connected, it calls next
• This puts execution inside getJarContents, where the uri looks like:
  
• After the manipulations to pathToJar it ends up being
  
• This results in an error when readFile is called:
  

[bpringe]

Aside from fixing this, we should also log the error so we have more insight if it errors in the future.

[bpringe]

Added a fix for the windows issue here: #918. If you approve and merge, then this PR looks good to go, aside from anything else you wanted to do. 😃