Add way to "Go to offset", ideally accessible from the "Go to" command

[jfthuong]

It sometimes useful to be able to go a certain offset of a file (e.g. when a tool reports "error xxx at position 599").

This has been implemented for vscode-hexeditor and it would be nice to have this mainstream and built-in (rather than having to depend on some extensions ... that might be buggy).

A nice way to access it would be from Go-to (Ctrl + G) as it is the case in Notepad++ for example, maybe like:

• :n would go to line n
• :n:c would go to character c of line n
• ::c would go to the character c of the whole file (i.e. offset)

The first two being already implemented, that would be the logical continuation

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[treystout]

On teams making use of transpiled/concatenated code this would be very nice to have. It's impractical to get the character offset by highlighting the text in a very large file. +1 for the suggested ::c solution, would also be nice to make it available to the command palette.

[soulshined]

I am the developer of an extension that attempts to satisfy this need https://marketplace.visualstudio.com/items?itemName=davidfreer.go-to-character-position

I have some concerns about this being an extension and I would submit this should circumvent the normal 'voting' phase as this is a core function of text editing software. But that's just my 2 cents.

I'll briefly explain some issues I've ran into as a developer of an extension targeted towards this purpose, more so the limitations of the vscode api afforded to extensions

1. 50 MB extension host file limit re Cannot execute command because there is no active text editor when file is not tokenized #146784 Obviously, this negatively impacts simple/navigation focused extensions like this

2. Line Ending Normalization. As commented by the OP here, an issue was submitted to my extensions repository Position is counted incorrectly when reading a file with mixed EOL soulshined/vscode-jump-to-character-position#4 identifying the same (that extensions may or may not be calculating positions correctly). After review I am left with the impression that because I strictly use the tools afforded to extension developers there's only so much I can do to accommodate needs like this, and similar future needs. The api is extremely limiting for this particular scenario, and even exploring the route of using conventional node file system apis proved fruitless Position is counted incorrectly when reading a file with mixed EOL soulshined/vscode-jump-to-character-position#4 (comment)

3. What is 'absolute positioning' is it 1 based or 0 based? My extension supports this variant but was an outcome of internal testing feedback

4. As an extension developer I strictly rely on the https://code.visualstudio.com/api/references/vscode-api#TextDocument.positionAt api method for calculating, so all of it's respective logic is not under my purview.

   For example, I don't know how multi-byte characters are accounted for. I don't know how localization is accounted for. I don't know how line endings are accounted for etc. All of which I can't control at a high level.

5. I've had requests off site of github to make this accessible. It's not immediately clear to me what that means or how I approach that yet. But if accessibility is a need I think that merits some internal team assistance

In most cases those issues solicit negative reviews from users due to the educational gap of what I can and can't do as an extension developer.

[vscodenpa]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!