goToError plugin navigates to a marker and opens the default editor. If that default editor is a CustomTextEditor the range is lost.

[mwadams]

Does this issue occur when all extensions are disabled?: No

• VS Code Version: 1.88.1
• OS Version: N/A

Steps to Reproduce:

1. Create a sample extension that contributes a CustomTextEditor as the "default" editor for a particular text document type. It should also register a diagnostics provider that can provides a single error diagnostic for some range of text in the text document (anything will do to illustrate the problem).
2. The diagnostic error appears in the errors window as expected.
3. When you click on the diagnostic VS navigates to the error. This causes the contributed custom text editor to be opened. But the position/range is lost. It is not exposed either via the URI, or by some other means.

Why does this happen?

Looking through the code, it appears that that goToError plugin uses the navigation/marker mechanism to open an editor.

The resource provided through this mechanism is an object which includes the URI and the Range information; as you walk the stack it ultimately sends that on to the custom editor provider and the resource you get there is just a URI. We have thrown away the range information.

Why is this a bug and not a feature request?

If it did not open the custom editor at all (but opened the built-in editor instead) I would consider this be a feature request. (A feature I would very much like!)

But as there is no way of telling the Error widget to open the built-in editor instead of the default, the error window in fact fails to navigate to the correct location, so I would consider this to be a bug.

Potential solutions:

One alternative would be to add an optional family of "revealRangeNearTop()" etc. methods to the custom text editor interface and make use of them. This has the advantage of reflecting the way the built in text editor works, while deferring the implementation of the active selection etc. to the custom editor itself; it doesn't impose additional state on VS.

Another option might be to encode the desired range in the fragment of the URI rather like the existing LXX,YY used to open at a specific location. This has the advantage of being minimally invasive, but is a bit gnarly!