-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ecto plugin #104
Comments
@lukaszsamson to clarify, the question would be, can the type inference logic you're working on help here? Or do we need to do something from scratch? |
I just want to say that having these completions be a possibility is very exciting! |
Sorry for a late answer, I didn't have time to look into this earlier. This looks awesome and I guess you've already figured out the details. Anyway, here are my answers:
It depends if we are able to get the correct AST
If we are able
then it should be easy.
It can be useful. I'd try to parse and transform Ecto macros into a format that Binding module can understand.
into
I wonder if adding support for pipe style queries, i.e.
or subqueries
would need much work. |
Hi folks! I'm almost done here. It took much longer than I thought. I couldn't resist and ended up implementing the ability to handle functions without parens since it's the most common way we see people using A great side effect of that change is that signature hint (or anything else that depends on Since we need to deal with incomplete code when autocompleting, we'll never be able to cover all possible scenarios, but I think the new implementation should cover the most common cases we have.
I wouldn't care much about pipe style for now, however, if we could infer types of queryables, that would be just awesome. For instance, in your example:
I'm not able to retrieve the type of |
@axelson are you ok with moving the module attribute snippets to ElixirSense? I think we shouldn't have any suggestions provided by ElixirLS itself. One great thing about the new implementation is that it allows us to provide very precise context-aware suggestions. That means we can add or remove suggestions according to the knowledge with have about the code. In the Ecto plugin, for instance, we can restrict the list to the minimum we believe that might be meaningful. For instance: Listing available schemas in Listing available options for As you can see, ElixirLS adds those extra suggestions for both cases and there's nothing we can do about it from the ElixirSense side even though we know they are not applicable in the current context. In case you agree, I can move that to ElixirSense in the context of Ecto plugin's PR. |
@msaraiva I do think it makes sense in this case. Especially as ElixirLS is calling Although I do think that historically most of those completions were added to ElixirLS because jake wouldn't have been able to add them directly to ElixirSense. The current splitting of the completions feels a little awkward as a result. |
@axelson we can certainly start accepting a few configurations in ElixirSense. I think that will be important in the near future as we start to explore more context/function/argument aware suggestions. Ideally, we shouldn't probably have any suggestion nor general customization of suggestions on the ElixirLS side. In order to have a flexible API for the plugins, I have created a new type of suggestion called @type generic :: %{
label: String.t(),
detail: String.t() | nil,
documentation: String.t() | nil,
insert_text: String.t() | nil,
snippet: String.t() | nil,
priority: integer() | nil,
kind: String.t()
} This way, when adding a different type of suggestion introduced by a plugin, we don't need to update ElixirLS to handle that suggestion. All different types of suggestions for the Ecto plugin are using I'll send the PR for ElixirLS to handle the generic type along with the Ecto plugin. Then we can start incrementally to move some of the other types if we find it necessary. The only one I want to move right away is the module attribute snippets as they are the only one that does not respect the restrictions imposed by the suggestions' engine as shown in the examples above. |
That sounds good to me 👍 |
I'm working on a plugin to improve
Ecto
support for editors. The first two features are:field
oradd
. Example:from
:@lukaszsamson in the example above, how hard would be to identify the variable
u
as an instance of%User{}
?The text was updated successfully, but these errors were encountered: