resourceLabelFormatters support more variables like ${query.*}

[eamodio]

I've been playing with the new resourceLabelFormatters extension point and I'm not really sure I'm getting it fully.

First, it doesn't seem like it applies everywhere in the UI -- for example, the tooltips on tabs don't seem to be affected.

Also what is workspaceSuffix used for? I can't seem to see any change when using it. Also is there any more formatting possible with label or just the url tokens?

Any help/clarification would be great -- thanks!

/cc @isidorn

[eamodio]

I would also really like to be able strip the leading / from the ${path} and also maybe have an OS-dependent separator (or set separator to undefined or null to indicate to use the right one for the OS)

[isidorn]

@eamodio the formatters should be applied everywhere in the UX. If not we need to adopt it in the missing places. @bpasero for using the label service in the tabs tooltips.
@eamodio are there other places where the formatting is not respected?

workspaceSuffix should be visible in the explorer title area for example. Do you see it there?
Stripping the leading / from the ${path} is currently not supported, also indicating an OS seperator.
Though we could add this.
Do you have more feedback regarding this feture?

[bpasero]

@isidorn I would assume this possibly should work already because I end up calling EditorInput.getDescription(LONG) which seems to be this.labelService.getUriLabel(this.resource)

[isidorn]

It seems like you are doing the right thing

[bpasero]

🏆

[eamodio]

The tooltip on the tabs has been fixed since I reported it -- thanks! As for the workspaceSuffix I'm definitely missing something. Since AFAIK you can't open a folder that isn't a real on disk folder, the title that shows up on the explorer title area is the name of the workspace itself, and inside the explorer view where the name of the folder is shown the suffix doesn't show up.

IMO stripping the leading / would be a great option as would having an OS dependent separator:

Supporting more advance matching would be great. For example in GitLens (see the above screenshot) -- I pack the git ref into the authority of the Uri, which is challenging when the ref is a branch name (since branches can contain / which I have to swap out for a unicode character that looks similar to / so it will be displayed -- just encoding it didn't work). If I could avoid packing anything in the authority it would be helpful. I also pack a json object into the query string (similar to the built-in Git extension) which has many properties with details about the uri reference

See the code here:
https://github.com/eamodio/vscode-gitlens/blob/15d57bc797973f95c167784d182e1b27dc8e9a09/src/git/gitUri.ts#L400-L406

So it would be wonderful if there was a variable syntax that could pull data out of the query string (and assume it is an object) -- e.g. ${qs.<property-name>} and if it failed (or returns undefined/null) for any reason it would just get coerced into an empty string. Or could go further and support something like ${qs.<property-name>|<missing-value>} where any failure/falsy would use the <missing-value> instead -- but I don't think that is necessarily needed (since an ext can always add a different prop to the qs object for that if needed).

That would allow me to get rid of the strange authority packing and hacks, and just use the querystring directly as below:

        "resourceLabelFormatters": [
            {
                "scheme": "gitlens",
                "authority": "*",
                "formatting": {
                    "label": "${path} (${qs.ref})",
                    "separator": "/"
                }
            }
        ],

@isidorn Thoughts?

[isidorn]

@eamodio Thanks a lot for feedback, however I just came back from vacation and am catching up with a bunch of issues. Will be able to only get back to you next milestone probably.

[isidorn]

@eamodio ok I have processed your feedback.
You want that the resource label service supports more variables.
#{qs.ref} for query string.

Due to that I will rename this issue and mark it as a feature request. Though this is not on our immediate plan I think it makes sense overall.

[eamodio]

@isidorn would a PR for this be accepted?

[isidorn]

@eamodio yes if it is not overly complex.
Code pointer https://github.com/Microsoft/vscode/blob/1c4857aa4a3c5101eb3b8e4afbfaea80c217abbd/src/vs/workbench/services/label/common/labelService.ts#L221

[isidorn]

Fixed via #71874

[jrieken]

@isidorn What's to verify here? Is this new (soft) API? Did you settle on qs, iff so why not query as all other names following URI naming?

[isidorn]

Yes this is kind of new soft proposed API.
Currently we only supported scheme authority and path. And this is adding qs.
And yes query might be a better name here.
To verify: code review + current unit tests should be fine.
Since in practice I believe only GitLens is using this and @eamodio already veriified it works.

[jrieken]

Ok, reopening then to change the name to query.

[eamodio]

@jrieken do you want me to send another PR? Or can I just push the changes to the same PR (even though its been merged)?

[jrieken]

I'd say, better a new one

[eamodio]

Incoming shortly...

[isidorn]

Adderessed via #78190