Change:
export interface IDefaultEditor { readonly uri: UriComponents; <ins> /** * @deprecated Use options instead */ </ins> readonly selection?: IRange; readonly openOnlyIfExists?: boolean; <ins> /** * @deprecated Use options.override instead */ </ins> readonly openWith?: string; <ins> readonly options?: IEditorOptions; </ins> } export interface IDefaultLayout {

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Provide a url for cell locations like
cc:
Dig into this a bit and find that to make this happen, it would require following changes: GitHub Repositories: support url fragment like in addition to and convert them into path in syntax RemoteHub: parse the file path and convert it to VS Code supports selecting a cell with editaor . This means we would need to update options.
Discussed offline with , with above items we can make the cell index url work in VS Code desktop with remote hub. To support the url in the embedders need to support this syntax the embed api should support notebook cell index
<img width="1125" alt="image" src="https://user-"Above diagrams show what changes we might need to make to support this style of link needs to support parsing the link for embedders now only support text editor options, we want to extend it to support others github/azurerepo extensions need to support the fragment in their link/repo opener remotehub supports parsing it too (it's using a different but generic syntax) command only supports text editor options. we either extend it, or remotehub uses api with cell index + cell editor selection support explicitly to support to support generic editor options, other than just .
Had offline discussions with and on proposed changes to have the notebook cell index support in Web scenarios (). Here is the gist of our discussions and some of our proposals. are constructing the workbench based on the info from the url (parse the path and fragments) and providing the default views and editors to open to VS Code. The workbench construction info is defined as is a combination of resource uri, and . Internally we will construct with and (converted to ). Challenge here is is not compatible with Notebook Editors. We talked about 3 options of extending the to support notebook editor options First one is extending . is used to allow resources to be opened in a custom/notebook editor. It already has the knowledge of custom editor so this proposal extends it to carry editor options for the custom editor Second option is replacing with a real , instead of constructing editor options from later on. For text editor, the options can be as simple as and for notebooks it would be .

Exposing the whole might be overwhelming so we can also limit properties on the options Last options is from The idea behind this is passing the original fragment and query parameters of the browser url to the custom editor opening the resource and the custom editor itself can decide how it wants to parse the fragment/params. I'd love to have feedbacks from and especially on what approach we take to extend the editor options support in web embedder api.
I like the idea that we make it the editor resolver's responsibility to parse a into a and . I think we should not have a top level in our default editor as a consequence, but rather make the text editor resolver fit to extract that line/col info and apply it to the options. The idea from core workbench editor service was always that is opaque: you can pass in any editor specific options such as notebook options and the options will get transported through. So an alternative would be to expose in the default editor, I think that is fine as well. being so prominent in the core workbench API is a bit of a left over from before we had the editor resolver. I would argue that today it should move into respective text editor resolver and not be so prominent...
I think we already picked a solution for the opener to convert the into + options via: and
I like this idea. It would be natural if the editor resolver parse the resource Uri but it seems now that we have quite some syntax for file fragment. The EditorOpener, the QuickAccess, the CLI and lastly all have different styles of line/col syntax. It will be quite some effort to unify them and have a standard of way constructing/parsing the to in the same resolver. Also mentioned there is probably a reason why we didn't put the fragment in the , would love to hear more about the reasoning behind this. <img width="1211" alt="image" src="https://user-"Since the reality now is each editorService user has their own logic of handling Uri#fragment. I actually prefer this a bit more. The workbench editor service get an object and pass it to custom editor without worrying how its shape (as long as it matches ). The changes are quite minimal and straight-forward (PR ) and I tested that the editor options are passed to the notebook editor seamlessly.

There is always a risk that encoding these kind of options in the ends up introducing the into the system in that form because someone forgets to rewrite the to + . So a model where resource and options are clearly separated is actually nicer, now that I think about it. From the editor point of view (and in many cases due to our utils), a resource that is different only in or is still considered to not being equal to the same resource with different or . For the opener we probably did not have much choice because the protocol service in the OS only allows to pass in a path to the application and not additional information, so we end up encoding everything into that path. I think a similar challenge exists for drag and drop where the transfer object is most often also just a resource.
I tried testing this by running in , but that resulted in a URL containing only lines and not the cell index. How should this be verified?
Doesn't seem to work for me, open the wrong notebook for when giving it https://user-
that URL seems malformed, should it be
Oh, you are right. Closing as verified but I really need an action to generate these links for me