Increase number of available matches

[darianmorat]

As the title says, an option for being able to search just forwards or just backwards, since I know what I'm looking for, why should I also search on both sides? For example, with a remap that would use: s = forward & S = backward.

EDIT: Also a good idea would be to change the matches options, what I mean is that when there't too many matches you start to get MAYUS, and you need to reach shift for that specific word, I would suggest more use of double words matches like fj, sk, ld, etc, in that way you don't loose the flow, or ; that is easier to reach, that can improve more the efficiency

[tranhl]

@darianmorat Thanks for taking the time to make a suggestion!

The extension searches in both directions (even if you know what you're looking for) as having to trigger search in the correct direction is an additional decision that the user has to make. I don't see this changing as my intention with this extension was to simplify code navigation in VSCode. Adding more options would go against this philosophy.

What issues are you experiencing with the current search behaviour? Are you having problems with the number of available search tokens? I can definitely see that being a problem if there are a lot of matches for the search term.

Two-letter search tokens are technically possible, however I'd prefer to not go down that route for several reasons:

1. Would we use two-letter match tokens as a default? This would decrease the simplicity of the extension.
2. If we don't display two-letter matches by default, when would we then? This would introduce bimodal behaviour in the extension. Sometimes it only displays single letter matches. Sometimes it displays double-letter matches. This would go against the principle of least astonishment.
3. We would have to uplift the match tokeniser to both generate valid two-letter sequences and provide visual feedback when the user enters the first letter of a match. This is a non-trivial amount of work.

I'm keen to hear your thoughts so that we can come up with a solution for your workflow!

[darianmorat]

@tranhl You are right with all of your points. After using your extension more, I did realize how good it actually is.

1. The input, the reason why most vowels are not used is cause this allows you to extend the search without interruption, (This is so different to other motions that just allow you to search 1 or 2 characters, with your extension we can search the whole word instead).

2. Certainly is needed to use mayus when we have more matches: (shift is harder to reach so for that reason my concern, but I don't see any other better option for it).
   2.1. Yes, using two characters will kill the simplicity.
   2.2. If you have more matches, just specify more of your input and is going to search that specific word.

3. The use of just 1 stroke for a search in the whole view kills that thinking for direction, so you are also right.

But I think that adding ; as a match would give 1 extra option for matches that is my main concern without the use of Shift when there are more matches, since is not really used, and I couldn't find any situation where ; is needed or could affect the search, plus is easy to reach.

An extra suggestion that is more about looks, is the search box that appears at the top, and sometimes can hide 1-3 lines from your view (depends on editor settings, large GUI and using just half of the screen), moving the input to the status bar would be much better in my opinion, just that detail.

No more to comments about it. And thanks, is an excellent extension.

[tranhl]

I'm glad you like the extension!

The input, the reason why most vowels are not used is cause this allows you to extend the search without interruption, (This is so different to other motions that just allow you to search 1 or 2 characters, with your extension we can search the whole word instead).

Definitely, that's the biggest convenience of the extension. I think we can do more to explain how the extension works in the README, the GIF doesn't do a good enough job I think.

Certainly is needed to use mayus when we have more matches

100% agree with you here. There is room for improvement, as right now the extension filters out the next 8 characters after a match from the available jump characters. This is to handle someone typing really fast and accidentally triggering a jump. Perhaps a debounce function can be used to prevent jumping during typing.

An extra suggestion that is more about looks, is the search box that appears at the top, and sometimes can hide 1-3 lines from your view (depends on editor settings, large GUI and using just half of the screen), moving the input to the status bar would be much better in my opinion, just that detail.

The extension was first implemented in the status bar, however it created a long list of bugs that could only be resolved by swapping to the text box input. I don't see this changing.

Thanks again for taking the time to report this issue!