The default label for multiple declarations is not useful

[ylussaud]

The computed label for multiple declarations is the name and the path of the resource with is not really useful as an end user.

It would be better to display the line declaring the symbol so the used can select the relevant entry. This could be done at least for IFile from the workspace since we can have the encoding and the stream to read its content.

[mickaelistria]

I'm not sure I understand what you're talking about. Can you please submit some screenshot of the particular UI element being discussed?

[rubenporras]

Yes, an screenshot with and without your PR would be very helpful. I know how it currently looks like, but I am not sure about how it would look like after

[ylussaud]

Before the patch:

After the patch:

I updated my commit...

[rubenporras]

I am unsure on this change. I see how in some cases the declaration line might be useful, but the URI might be as well quite relevant. Would the problem be solved if the dropdown menu that shows the URI would be wider?

[mickaelistria]

Showing the line content can be helpful, but it IMO usually seems more important to show the target location as well (and not only its content). Also not that in some cases, the first line of the declaration might not be so interesting. It could for example be the start of a comment. The line content might be a nice addition as a suffix, but we'd need more space.
I think we can maybe save some space by replacing the "Open" by an arrow emoji ➡️ , Also we might be able to only show some relative paths when they're shorter; then we could have more room to append line content.

[ylussaud]

In my case all declarations are in the same file so there is no way to distinguish a declaration from its URI. Maybe this choice should be done by the language implementation via an extension point ? This extension point could include other labels as well.

[mickaelistria]

choice should be done by the language implementation via an extension point ?

I fear it's a dangerous to have extension points for it, as at such pace, we'd start maintaining dozens of extension points for everything. How does VSCode behave in this case? Maybe adding a "label" to LocationLink in the spec would be the best way forward.

[ylussaud]

I understand, in the mean time could:

Declaration - <resource name> - <line content>
Declaration - body.mtl - [template public generateClassifier(cls : ecore::EClassifier)]

be an option ?

[rubenporras]

At least for our use cases, the file name would not be enough, the folders are also relevant.

I wonder, for the cases where the URI is not enough, should one not use type hierarchy? Would that work for you?

[ylussaud]

No those are declarations not related to types in the language. I'll try to find a workaround...

[ylussaud]

I provided my own org.eclipse.ui.workbench.texteditor.hyperlinkDetectors as a workaround. I still have the hyperlink detector from LSP4E but I can live with that for the moment.
For more details one can check this commit.