Closed Daniel-V1 closed 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?
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.
This is nice to see the types in the completion list.
But I wind up having to delete most of whats injected.
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.
Which LSP client are you using on emacs?
Lsp-scala. Yep, looks like its working fine for you there, so its probably a client bug. Thanks for confirming
@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?
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
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
?
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
@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.
@gabro Thanks for the heads up about the gitter channel. I'm never sure which repos have active ones.
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