Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow extensions to determine if a position is within a fold. #22276
This is currently the most demanded features of VSCodeVim: VSCodeVim/Vim#1004
The main problem with Folds and Vim is that some motions will skip right over folded areas (like moving up/down). We need to know if we are in a folded area so we can iterate these motions until we are out of the fold.
An API like
An API like
@alexandrudima since you brought it up in that other ticket for wrappedLine info. Instead of having the entire files worth of info, is it possible to have properties for the immediate line (inAFold, charLineStart, charLineEnd )? Is the folding information simpler or any different than the wrapped line info? Any suggestions for how else we can get this information?
We have another issue somewhere where we discussed this. The recommended path forward is for the vim extension to continue invoking the
We have no plans to expose view model information (which we consider implementation detail of the editor) to API.
@alexandrudima Thanks for your quick response :-)
Well, That's very sad to hear considering VIM extensions are useless without this API.
Why do you guys think querying the
@alexandrudima For reasons I am not entirely clear on, you guys have decided not to expose fold information to extensions. That's fine!
However, in the absence of that, there are some things we need alternatives for. There's 2 main things vscodevim needs improvements on. I've read much of the discussion surrounding this, and I don't think either of these suggestions should be particularly objectionable.
First, we don't actually need an
Second, expand the API calls for folding. I could come up with a more extensive list of what we would need minimally, but here's a very simple example. For
Additional notes: One other thing. Desired column, as in #23045, is very tricky for us to handle, even with the additional API calls provided above. I have some ideas for better ways to handle this, but I'll leave those for another day.
I hope you guys appreciate how much my hack here for fixing folds hurts my soul: https://github.com/VSCodeVim/Vim/pull/1552/files#diff-944e6e33fb41f3b52eec89cd786de750R242
Due to the complexity and quantity of Vim motions, cursorMove is not an acceptable fix for folds inside VSCodeVim.
Nor will it ever be, because VSCodeVim allows custom motion creation and extension support.
I just want to be clear here: Vim's motions are too complex and varied for a Vim extension to ever consider
I hope that you reconsider.
I am open to reconsidering and I'm sorry for this being so annoyingly hard.
Here are my concerns and my trail of thoughts:
This was all a big introduction to why my default reply to adding more reading API is always to start the conversation with no. That is because any reading API must be synchronous and must be pushed eagerly by the UI process to the extension host.
I'm always aware of the fact that adding more reading API means sending all the data necessary for it to the extension host even if there is nobody interested in actually reading. For example, I am asked many times to provide a getScopesAtPosition API, since we technically have that information on the UI side or could compute it fairly quickly. But again, that would need to be something pushed eagerly for it to work with the above state guarantee. For example, if we will add scope reading API, I think we should implement it by tokenizing as needed on the extension host process, rather than always pushing tokens to the extension host.
Ok, so enough about general problems. Specifically my concerns on the view / model coordinate system:
@alexandrudima Could you explain why
To quote the API command's description:
I don't understand how moving the cursor into a fold would be interpreted as a "logical" position in the view.
This just seems like a strange API decision. If extensions wanted to always move down into a fold, they could just do it manually.
EDIT: Actually, I took a look at the source code and I see why. There is only a modelState (which has no notion of folds or wrapped lines) and there is a viewState (which always knows folds/wrapped lines). Thus, there's no easy way of ignoring only wrapped lines.
However, other than the difficulties with the internal representation, offering a