Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API request: Live Positions #8094

Closed
johnfn opened this issue Jun 24, 2016 · 4 comments
Closed

API request: Live Positions #8094

johnfn opened this issue Jun 24, 2016 · 4 comments
Labels
api feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code
Milestone

Comments

@johnfn
Copy link
Contributor

johnfn commented Jun 24, 2016

In the process of working on a Vim plugin for VSCode I've run into a number of areas where I need a little bit of API help. Apologies if any of my suggestions already exist!

Vim has the concept of marks, which are positions in the document that you can jump to from anywhere. They're like the Positions the API provides, but if you delete text from before the mark, the position of the mark will change.

It seems highly likely that you guys have something like this internally, and I think it would be disappointing (and possibly difficult) to roll my own. Help?

@jrieken jrieken removed their assignment Jun 24, 2016
@jrieken
Copy link
Member

jrieken commented Jun 24, 2016

Yeah, our decorations are implemented like that

@alexdima
Copy link
Member

The challenge here is that we don't sync decorations back to the extension host. We could do that proactively in case someone wants to read them and then provide synchronous read API. IMHO async read API would be unsuitable in this case.

@siegebell
Copy link

At least, I would like to see the API provide utility data structures that manage sets of ranges and sets of positions, allows updating them in response to a TextEdit, and provides some basic functions like searching for intersecting ranges.

I've written this myself, but it is easy to get wrong, I imagine a bunch of extension authors would also find the functionality useful, and counting the line delta in a TextEdit is a pain in the butt because you have to parse the line endings yourself.

Then vscode would not have to directly provide the updated decorations to the extension, which I imagine raises some asynchrony issues because decorations tend to be updated well before the extension is done processing edit updates.

@johnfn johnfn mentioned this issue Jul 9, 2016
89 tasks
@egamma egamma mentioned this issue Jul 9, 2016
4 tasks
@alexdima alexdima added the feature-request Request for new features or functionality label Jul 11, 2016
@alexdima alexdima added this to the Backlog milestone Jul 11, 2016
@alexdima alexdima removed their assignment Nov 24, 2017
@alexdima alexdima added the *out-of-scope Posted issue is not in scope of VS Code label Sep 20, 2018
@vscodebot
Copy link

vscodebot bot commented Sep 20, 2018

This iteration we focus on issue grooming. This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

@vscodebot vscodebot bot closed this as completed Sep 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code
Projects
None yet
Development

No branches or pull requests

5 participants