Add support for textDocument/hover (for modules)

[zachallaun]

This first commit is essentially just scaffolding, including the generated types for textDocument/hover and basic request/response handling. It currently replies with static content.

There's some additional WIP code for retrieving the docs for the entity being hovered, but I'm not sure how much of it will actually end up in the final feature.

---

@scohen, some thoughts/questions on the best way to proceed that I'd love your input on.

1. The hover response contains two things, an optional range, representing the entity that you retrieved hover content for, and the contents themselves as markdown. For this initial implementation, I'd thinking to handle modules, functions, and types -- see the Project.Docs fixture for what I'm planning to test with to start. Does this seem reasonable?
2. I'm planning to use Code.fetch_docs/1 to retrieve docs. It retrieves docs for an entire module, all functions/types/etc. defined within. As per (Added thoughts about code intelligence and indexing #223), it'll eventually be worth caching this stuff, but for now I'm thinking to just scan the result each time.
3. Go-to-definition currently uses ElixirSense to retrieve the definition given a doc/line/character. I'm assuming that I should also use it for now to retrieve the range and module associated with the currently hovered entity?

[zachallaun]

4. This shares a lot of behavior with Definition -- I'm inclined to co-locate them instead of adding a new Docs or something.

[scohen]

@zachallaun

1. Yes, this seems reasonable. I'd even say this sounds like a lot, perhaps start with modules and functions?
2. Go for it, I haven't made any progresson the intelligence and indexing features.
3. I would like to stay away from elixir_sense, as it's a dependency that is going away, and doesn't have a release cycle or versioning. I do understand that identifying stuff under the cursor is pretty tricky in elixir. I'd like your thoughts on what you feel comfortable doing.
4. Ok, maybe the name Definition needs work then?

[zachallaun]

1. Let's see how much we get "for free" -- the hard part is figuring out the entity under cursor, after that it's just filtering a list.
2. 👍
3. This is somewhat related to co-locating with Definition, which also relies on elixir_sense. So if we co-locate, I'll factor things such that when elixir_sense is removed, there's a minimal interface to replace. I'll keep an eye on opportunities to remove dependence on it, though. Using Code.fetch_docs directly is one such opportunity already, vs. ElixirSense.docs.
4. Agreed, I was going to bring that up. CodeEntity? Just Entity? Artifact? I'm not really sure what the nomenclature should be -- basically any unit that can be defined somewhere and referred to either by an atom or module-function-arity.

[scohen]

1. This is what's dangerous about using ElixirSense; you get a LOT for free, and then it becomes super hard to replace the whole lot. At this point, I'd almost favor going the other way and starting small with, say Modules, and working our way up.
4. I'd favor SytaxEntity or CodeEntity. Perhaps in a Syntax.Entity or Code.Entity module. Thoughts?

[zachallaun]

1. Sounds good -- I'll start with modules and see if we can avoid elixir sense altogether. Basically these cases:

Some.Module| # docs for Some.Module

alias Some.Module
Module| # docs for Some.Module

Some.Module|. # compile error, should still be able to identify Some.Module

Some|.Module # docs for Some

4. I think Code.Entity makes sense. This is pretty foundational, probably the kind of thing that will be in shared or common eventually (plugins will want access to it, methinks). So it'll basically be Lexical.Code.Entity, I think?

[scohen]

Aliases can get pretty tricky, but luckily we have an alias tracker in lib/lexical/code_mod/ast/aliases.ex It allows you to give the ast and then do Aliases.at(doc, position) which in your second example, will give you a map of %{:Module => Elixir.Some.Module}

[scohen]

So it'll basically be Lexical.Code.Entity, I think?

Yep, start off in common and if we need it in plugins, we'll move it to lexical_shared.

[zachallaun]

I'm going to mark this PR as ready for review. Currently it is able to resolve modules under the cursor and display module docs. The code (and commits) need to be cleaned up a bit, however. That said, I think it's in a good-enough spot that it's useful to get feedback and make sure I'm not too far astray.

[scohen]

Wow, what an improvement. I'm really liking the direction here (and I can't wait until we can get Ast.fragment merged so I can use it in my indexer PR.

I would like to call out the tests though, I think (hope) we can improve them so that each test clearly shows both the module being defined (and its docs, or lack thereof) and the module being hovered over.

[scottming]

I noticed that this PR also supports built-in Elixir modules like Enum, so I think we might need to add support for Hexdocs links.

Like livebook:

Additionally, I found that when the cursor is on a dot, it displays the documentation for the previous module, which is great. However, it doesn't work when there are no functions or submodules following it, like Lexical.|, but Lexical.|RemoteControl will work.

[zachallaun]

I noticed that this PR also supports built-in Elixir modules like Enum, so I think we might need to add support for Hexdocs links.

Those aren't embedded in the module docs, but added after the fact. I do think it is worth adding them (Elixir LS does as well), but I'd rather that happen in another PR.

Additionally, I found that when the cursor is on a dot, it displays the documentation for the previous module, which is great. However, it doesn't work when there are no functions or submodules following it, like Lexical.|, but Lexical.|RemoteControl will work.

Will look into it!

[zachallaun]

@scohen @scottming I believe everything that's been mentioned so far has been addressed. Please let me know what else y'all would like to see prior to merge!