Show res:// path instead of uid:// in ScriptEditor

[masterthdev]

Describe the project you are working on

Any project

Describe the problem or limitation you are having in your project

Currently uids show a tooltip when hovering in ScriptEditor. Using Ctrl+LMB on the uid opens the file. There is no way to see any information without moving the mouse cursor over the uid.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Showing res:// path instead of uid would solve the problem.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Editor will show res:// path by default instead of uid://, with an editor settings to disable it if necessary. Clicking on the path will reveal the uid.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I don't know if it is possible with an editor plugin.

Is there a reason why this should be core and not an add-on in the asset library?

This improves editor functionality for everyone using uids.

Bugsquad edit: Keywords for easier search: code folding, inline preview

[Ivorforce]

I agree with your sentiment that showing the uid:// in the string isn't very helpful. I think it may even lead to users using paths instead of uid in many cases. The hover is... fine, but it leaves room for improvement.

However, completely replacing the text in the editor is unrealistic. You definitely need the "uid" information at a glance, too.

There is one other solution - IDEA-like text widgets:

(imagine this says icon.svg)

However, this would be a separate proposal entirely, and would require quite a bit of refactor in the text editor. Not very realistic either, at least short-term!

[Zireael07]

How about having both path and uid in the tooltip? I agree that the path is useful to have available at a glance

[Calinou]

• Related to Improve autocompletion display in the script editor #11079 (specifically the inlay hints that were mentioned in a comment).

[HolonProduction]

You definitely need the "uid" information at a glance, too.

Why though? Like I get the uid thing on a technical level, but as a user I'm not really getting any information from it that I'd require at a glance.

There is one other solution - IDEA-like text widgets:

Showing only the filename might not be enough in a big project and showing the whole path in the inlays hint, would not look right for an inlay hint IMO.

Furthermore inlay hints are usually styled in way that implies that the hint is less important than the information it annotates. I'd argue that information wise the path is more important than the uid to the user.

[Ivorforce]

Why though? Like I get the uid thing on a technical level, but as a user I'm not really getting any information from it that I'd require at a glance.

The main reason to have it 'at a glance' is that I wouldn't want the text to change when I click into it.
The other reason is that i'd like to know at a glance what's actually in the text, and not what the editor interprets it as. That's just basic code editing sanity!

[HolonProduction]

That's just basic code editing sanity!

For editing sure (that's why it expands if you click and I believe also when entering with the cursor), but this feature targets code reading not editing. Given that this kind of feature is already in use in IDEA (e.g. for translations from resource bundles, the actual code is folded and the value is used as preview in Android Studio) I'd say that there are users who prefer seeing relevant information over the actual code (me for one).

That being said this is totally a feature which should be configurable as code editing preferences are highly subjective.

[Ivorforce]

True, code folds would be a good solution too!

[HolonProduction]

That's how IDEA implements this. It are folds that don't span multiple lines. LSP also seems to support a preview string since 3.17. Just not sure how well LSP editors would handle folds that start on the same line that they end.

And well when it comes to CodeEdit I see two points that would be needed to add this feature:

• support arbitrary range folding (currently only whole lines can be folded AFAIK) and custom folding previews
• expose and integrate folding to the ScriptLanguage api (would make sense to align this with the LSP spec for folding)