Call hierarchy: highlight call location for incoming calls

[jwortmann]

Based on a suggestion from sublimelsp/LSP-typescript#186 (comment).

For the incoming calls ("callers of...") in the call hierarchy, if you click on an item, it will currently open the first line of the function definition. But with this change, it would highlight the (first) location of the actual call within the function instead.

I've also tested what VSCode does, and it seems that it randomly highlights either the call location, or the first line of the function. And it randomly changes even for the same item... probably they have a bug somewhere.

Recording from VSCode

vscode-call-hierarchy.webm

Anyhow, I think it is more useful doing it this way (up for discussion).

The implementation is unfortunately very ugly, but I don't see a different way other than storing the location into the CallHierarchyItem itself, because a CallHierarchyItem is not necessarily unique, and the get_tree_item method to render an item has no other input. If someone sees a better way, any improvements are of course welcome.

[rchl]

Sorry but I still didn't quite like it due to loosening of the types and mixing wrapper item and normal items.

I've pushed an alternative fix that normalizes hierarchy items into a single HierarchyData structure (perhaps name is not ideal?). Let me know what you think.

[jwortmann]

This is not how it works. You lose information in the to_hierarchy_item function (e.g. data, alter the selectionRange). You need to preserve the CallHierarchyItem's / TypeHierarchyItem's as they are reported from the server, in order to make the new requests. Make sure the element in line 68 has the correct type. (CallHierarchyItem or TypeHierarchyItem, respectively)

[rchl]

Ok. I will look a bit more tomorrow. I thought that nothing else from the response was accessed.

And of course we can revert my commits if needed

[rchl]

Pushed alternative version that always uses a wrapper element.

[rchl]

Perhaps my changes make namings a bit inconsistent right now - element, data, item...

[jwortmann]

To be honest, I don't really like some of the new names. element should keep its name, because otherwise the overridden method signatures don't match the base class anymore. I'm surprised pyright doesn't emit an error for this. The reason why it was called element is, because that's the name from the VSCode API.

And I would still use HirarchyItemWrapper as the name instead of HierarchyData.

Besides that, I think it should work now and the other changes seem fine to me.

[jwortmann]

I can't approve my own pull request, but it looks good to me now.