When changes are accepted/rejected the Uris are not notebook friendly

[DonJayamanne]

Today
Its difficult to tell what cells were updated

Proposed

[DonJayamanne]

@bpasero I'd like to get a more user friendly url displayed in the chat panel for changes to notebook cells.
As you can see above, the changes that are accepted/rejected are not clearly defined as changes to cells.
The second screenshot is a proposed fix. The * Cell <number> is the standard display format for cell uris.

I'm not entirely sure whether making the change to the LabelService as in the PR is the right approach.
I've added a flag as I'm not entirely sure where this is used.
That being said, any Cell URI should ideally be displayed in the above mentioned format, thereby making the flag unnecessary.
Then again, not sure this is the right solution.

Please advice on how we can improve the display format.
Today the formatting is done in ResourceLabelWidget in https://github.com/microsoft/vscode/blob/influential-koala/src/vs/workbench/browser/labels.ts#L484

[bpasero]

Are these specific URIs for cells? Then why not register a handler for the formatting of these?

vscode/src/vs/workbench/services/label/common/labelService.ts

Line 437 in 0252e92

registerFormatter(formatter: ResourceLabelFormatter): IDisposable {

[DonJayamanne]

Are these specific URIs for cells?

Yes

Thanks I should have mentioned that I did look into that & unfortunately that formatter doesn't support setting prefixes to the Uri dynamically based on whether this is the first or second or third cell. & unfortunately that information isn't part of the Uri.

The only way I can do this is to register a formatter just before i invoke getUriLable for a specific Uri with the predefined suffix in the label e.g. * Cell 2 or the like. & then remove that formatter immediately after that.

I don't think thats right, after all I might as well manually add the suffix * Cell 2 to the label (string) returned by getUriLabel

[bpasero]

It smells like debt to me to encode notebook specific logic into a core service like labels, so I would not go down that path. Can you address this for now just in chat?