-
Notifications
You must be signed in to change notification settings - Fork 151
Custom request locate types #1584
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
base: master
Are you sure you want to change the base?
Conversation
706b78d to
ab9c8d4
Compare
| } | ||
| ``` | ||
|
|
||
| `set` is a compacted version of every occured types. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
I think the result spec here does not match the actually returned json ? Data objects have type and result fields
-
"every occured type" sounds very wrong 😅
-
Also, could you elaborate on the expected usage of the "set" field ? Does it provide information that is not available otherwise ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, in Emacs with the in-house xref extension, and in VSCode, the UI is very limitated, so from my POV, for the moment, we do not know how to deal with that kind of structural answer. So the set is just a compact way to handle every "reachable type", since we do not rebuilt the type expression inside the client.|
(So just iterating on set seems legit)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But could this compact representation be inferred from the rest of the result on the client side ? If it is, then is it really worth it to make the protocol more complex to spare that work to the clients ? (not saying we shouldn't, just trying to weight the pro and cons)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But could this compact representation be inferred from the rest of the result on the client side ?
Yes.
If it is, then is it really worth it to make the protocol more complex to spare that work to the clients ?
Yes I think it make sense when it is possible.
For me, the goal of the protocol is to give a quick-as-possible way to extend clients, so I expect from a client perspective to reduce the logic to handle at the client side. (Like for Type Enclosing)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright. (Still need to fix the doc so that it matches the actual results I think)
Add a custom request for
merlin-locate-typescc @liam923, the major difference of Merlin is the inclusion of the field
setwhich is a compact representation of every reacheables types.