search

scalameta / metals-feature-requests

Issue tracker for Metals feature requests
37 stars 4 forks source link

Auto-completion adding too much information #23

Closed Daniel-V1 closed 5 years ago

Daniel-V1 commented 5 years ago

Is your feature request related to a problem? Please describe. Autocomplete is great, but I think that including all the type information for everything is too much. I like to see it in the autocomplete options, but having it actually inject all the extra information is a bit much generally speaking, as most times I just have to delete it.

Describe the solution you'd like I would like to see auto-completion without type information injected.

Describe alternatives you've considered Currently I just delete backwards to just the parts that I need, which isn't hard, but is aggravating after a while.

Additional context I am using 0.5.1 and emacs, set up following the instructions given at https://scalameta.org/metals/docs/editors/emacs.html

Search terms: Autocomplete

gabro commented 5 years ago

@Daniel-V1 thanks for the opening the issue! I'm not sure I understand what you mean by including all the type information for everything, can you make an example?

Daniel-V1 commented 5 years ago

Sure. Maybe this is more a problem with the emacs client, but I'm not sure. If it is, feel free to close this issue. Also, thanks for the fast response.

list_with_types This is nice to see the types in the completion list.

types_injected But I wind up having to delete most of whats injected.

gabro commented 5 years ago

Do you mean that when the completion item is selected the client inserts the entire signature? That seems like a bug of the specific client, not interpreting the spec correctly.

This is the behavior I get on VSCode.

2019-05-03 17 36 23

Which LSP client are you using on emacs?

Daniel-V1 commented 5 years ago

Lsp-scala. Yep, looks like its working fine for you there, so its probably a client bug. Thanks for confirming

olafurpg commented 5 years ago

@Daniel-V1 Thank you for reporting! Is the neighborsWithHistory method generated by an "override def" completion? When you mean "all the type information for everything" do you mean the redundant Solver# prefix?

olafurpg commented 5 years ago

Aah, I'm sorry, looking at the screenshot again it looks like you mean the label for completion items is too detailed. The full signature of the method is included to help see differences between overloaded methods

Screenshot 2019-05-03 at 18 23 34

Observe that VS Code truncates the last item which is too long. I believe the emacs client could so something similar.

The Solver# prefix might be redundant, can you please provide a minimal definition for the neighborsWithHistory method including the enclosing class and inner classes like Solver#Move and Solver#Block?

Daniel-V1 commented 5 years ago

Its definitely a client issue, as in the gif above it is working correctly. My problem is just that the emacs lsp-scala client is not truncating the type signature of the completion when inserting, so where in the gif above gabro completes flatMap and just gets flatMap, with the lsp-scala emacs client, currently I get the entire type signature of the flatMap and its arguments inserted. So this issue is not actually a metals issue, but a client specific one. I appreciate you guys responding so quickly and I really appreciate metals! Thanks

gabro commented 5 years ago

@Daniel-V1 👍 I agree it should be a client bug. However it's the first time I see it reported and I know quite a lot of people use Metals via lsp-scala.

Wild guest: could it be an interop issue with the specific completion plugin? I know near to nothing about Emacs, but can try asking on the Gitter in the #lsp-scala channel.

Daniel-V1 commented 5 years ago

@gabro Thanks for the heads up about the gitter channel. I'm never sure which repos have active ones.