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

Index fixes #1190

Merged
merged 9 commits into from
Mar 11, 2017
Merged

Index fixes #1190

merged 9 commits into from
Mar 11, 2017

Conversation

xconverge
Copy link
Member

A few minor fixes, fixes #1188

if (prevSearchList[vimState.globalState.searchStateIndex] !== undefined) {
searchState.searchString = prevSearchList[vimState.globalState.searchStateIndex].searchString;
vimState.globalState.searchStateIndex -= 1;
}
} else if (key === "<down>") {
const prevSearchList = vimState.globalState.searchStatePrevious!;

// Preincrement if on boundary to prevent seeing the same search index twice
if (vimState.globalState.searchStateIndex === 0) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How come we increment twice when we start at 0? I don't quite follow.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise index is 0 and you can press up and down alternating and never see a different result

@xconverge
Copy link
Member Author

@johnfn this one is actually pretty solid even if it looks weird

What it fixes:

  • do a few searches, then use and to navigate them, when you get to the last search result or the first search result, you need to press up or down TWICE to get to the next one

  • on first char of first word of first line, would move it to the last char

@xconverge
Copy link
Member Author

@johnfn this is weird, but I would rather it be merged than closed...

@johnfn
Copy link
Member

johnfn commented Mar 10, 2017

Sorry for taking so long on this one. I had it incorrectly categorized as a WIP in my mind, so I totally forgot to come back to it.

The reason I hesitated here is this fix doesn't really make sense. The index value should be just an index into the array that you can walk up or down by pressing up or down respectively. I don't see anything about the structure of that task that requires a double increment at the borders, which makes me cautious about this PR. I would like the code to reflect the structure of the problem we try to solve.

That being said, I don't really understand the search history code all too well, because I didn't implement it. So if you tell me this is the best way, I'll trust your judgement.

@xconverge
Copy link
Member Author

There 100% has to be a better way with a handful of lines to do the same thing, this is just covering that up

let me take a peek, I will @johnfn you when its good to go

@xconverge
Copy link
Member Author

@johnfn I think that this reads better. Works even better since if you make it to the end of history you get "" so you can enter your own search

The key was when entering "/" or "?" or reaching the end, allowing the index to go past the end of the limit.

@johnfn
Copy link
Member

johnfn commented Mar 11, 2017

Alright, looks good to me now!

@johnfn johnfn merged commit 08ad945 into VSCodeVim:master Mar 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Search history and change list navigation require an extra press at the first and last index
2 participants