search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.96k stars 28.77k forks source link

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

Open jfthuong opened 11 months ago

jfthuong commented 11 months ago

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:

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

VSCodeTriageBot commented 11 months ago

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 commented 11 months ago

image 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 commented 11 months ago

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 #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 https://github.com/soulshined/vscode-jump-to-character-position/issues/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 https://github.com/soulshined/vscode-jump-to-character-position/issues/4#issuecomment-1783671477

  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.

VSCodeTriageBot commented 10 months ago

:slightly_smiling_face: 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!