Index files as they are modified

[vinistock]

Motivation

Closes #1908

Index files as they are modified rather than waiting until they are saved. This better reflects the state of the codebase as the user is coding.

Implementation

The idea is the following:

1. If a document is changed, without being managed by the client (that is, the file was never opened in the editor and it's not present in our Store), nothing changes. We still index the changes based on their file path
2. If the document is already managed by the client, then we simply add the declaration listener as part of all of the others in the combined requests and re-index the file as we are providing other features

The only extra thing is that we need to be able to handle ancestor changes even if the user hasn't saved the file, so I created a way to track those.

Automated Tests

Added some tests to ensure that we index declarations in unsaved files as they are being modified and also to ensure that we don't accidentally create duplicate entries, which is a risk if we accidentally forget to clean things up.

Manual Tests

1. Create a new file in the UI without saving it
2. Change the language mode to Ruby
3. Add a class declaration
4. Verify you get completion for the newly created class

[st0012]

Are there cases where the uri would be different than indexable.to_uri? If there are, can we capture them in test cases?

[andyw8]

Also perhaps we can swap the arguments order, and have uri default to indexable.uri?

[vinistock]

Yeah, I think we need to change IndexablePath to be simply an Indexable and then include the URI there. I was just trying to avoid parsing the same URI twice, but the code is ugly.

[andyw8]

Do we need to consider the case where someone saves a file outside of the current workspace?

[vinistock]

Do we need to consider the case where someone saves a file outside of the current workspace?

I don't believe so. If the document is not opened in the editor and it's outside of the current workspace, how would we know that it is relevant for the current project? Or in other words, how could we know which files to watch (we wouldn't want to watch all Ruby files in the computer)?

Note

I'm afraid that this PR is going to degrade performance very significantly. I'm going to re-think this and #2341 to ensure that we're not making the experience worse.

[andyw8]

Here's a reproduction of what I'm thinking of:

• Create new unsaved file (VS Code will recognize it as Ruby):

# typed: strict
# frozen_string_literal: true

module RubyLsp
  class Foo
  end
end

• Save it outside of workspace, e.g. to the Desktop as foo.rb
• Observe that completion is offered for RubyLsp::Foo from foo.rb

[vinistock]

I don't think we need to support that use case. Under what circumstances would someone want to do that? You can't even require that file without the full file path because Desktop is not going to be a part of your $LOAD_PATH.

[andyw8]

(I know changes are planned, just marking as reviewed so GitHub stops pinging me).

[vinistock]

Closing this for now. We need to re-think the approach.