fix(vscode-plugin): ignore non-existent ".git" files, support untitled/unsaved files on VS Code

[kiding]

Issues

Fixes #487. Fixes #382.

Description

This PR restricts clientOptions.documentSelector to the file and untitled scheme, and changes load_file_dictionary to always succeed on the untitled scheme. This will prevent the non-existent .git files from showing up in Problems since they use gitfs scheme¹, and make Harper work on untitled/unsaved files. HarperAddToFileDict should fail as expected.

VS Code's documentation² suggests there may be other schemes like untitled, http, ftp, etc. Harper never worked with untitled with an error saying ERROR harper_ls::backend: Unable to generate the file dictionary. Harper's file_dict_name assumes url is a file path, so this shouldn't break any preexisting feature.

Demo

N/A

How Has This Been Tested?

To test for untitled: open a new document, type Errorz, check Output, see no error. one error saying Did you mean to spell “Errorz” this way?.
To test for .git:

mkdir test && cd test
git init
echo 'Errorz' > test.txt
git add test.txt
code .

Check Problems, see no error for test.txt.git.

Checklist

• I have performed a self-review of my own code
• I have added tests to cover my changes

Footnotes

1. https://github.com/microsoft/vscode/pull/86674 ↩

2. https://code.visualstudio.com/api/references/document-selector ↩

[mcecode]

Thanks for addressing this issue! LGTM, just a few nitpicks.

[mcecode]

Just to note, if this is merged, we may also want to close #382 as not planned or won't fix since this would stop the VS Code extension from sending untitled files to harper-ls, which would prevent "Unable to generate the file dictionary." errors from occurring when opening untitled files but also will stop us from being able to support them going forward.

[kiding]

Done! Thank you.

[kiding]

@mcecode Decided to add the untitled support as well. load_file_dictionary returns an empty one when it encounters the untitled scheme; same behavior as there is no file dictionary for a given file. HarperAddToFileDict and save_file_dictionary would fail as expected.

[elijah-potter]

@kiding, does that mean unsaved documents (i.e. blank buffers that aren't on-disk) will now work for text editors other than VS Code?

[mcecode]

does that mean unsaved documents (i.e. blank buffers that aren't on-disk) will now work for text editors other than VS Code?

Only if they support the same URI scheme that VS Code uses which is "untitled".

[mcecode]

Thanks @kiding!

[kiding]

@elijah-potter Checked with the other supported editors, and it looks like it's a VS Code-specific behavior/change.

• Obsidian: Works since it always saves a file.
• Neovim: Doesn't work due to a possible bug on Neovim's end.
  • For an unsaved buffer, the URL received by harper-ls is file:///.
    • It is actually file://, but the path probably defaults to /.
  • It seems Neovim fails to find which buffer is file://.
    • :lua print(vim.uri_from_bufnr(1)) returns file:// which is expected.
    • :lua print(vim.uri_to_bufnr("file://")) returns 2 which is wrong, then Neovim opens the directory listing for / at buffer 2.
• Helix: Doesn't work since it doesn't spawn harper-ls before saving to a file.
• Emacs: Doesn't work since it doesn't call didOpen and subsequent requests before saving to a file.
• Zed: Doesn't work since it doesn't start language servers before saving to and opening the file.