3 beta does not find some targets for single character

[andresdominguez]

@breandan

Steps to reproduce:

1. Command ;
2. Enter the "i" key

Expected
Yhe id tokens on lines 14-16 should be highlighted

Actual
Nothing happens

[breandan]

Hey Andres, thanks for the excellent feedback! My goal for this release was to support two modes of selection: tags and search. We're not completely there yet, because it is tricky to get the two modes to work well together. For example, in this case, if you type:

1. Command ;
2. Type "id"
3. Select a tag.

It should offer a single character jump for one of the instances of "id" on lines 14-16. If we were to tag all instances of the letter "i" immediately using the existing method, we would need to use a few 2-letter tags. In the current release, you type a little bit more, and press a single keystroke. Note that in either case, the maximum number of required keystrokes is 5.

In order to support search and tag-based selection seamlessly, we never change a tag, once it is assigned. So if we are going to assign 100% of tags as soon as a single character is typed, it's important to assign them so that no matter which path the user takes (by selecting an existing tag, or searching further for a string in the editor), there are no collisions.

This is possible, but requires us to pre-compute every possible string a user might type for every screenful. It's possible, but 1) I haven't tested what impact that might have on performance and 2) I'm not sure if anyone will need or even use this search feature. I'd appreciate any advice you might have in that regard. Thanks!

[breandan]

Feel free to disregard the previous wall of text, the two modes are now able to work together. Although we are only tagging one letter per word at the moment - for example if you type Ctrl+;, i it will only tag the first 'i' in "skiing". Likewise, it will only tag one 'i' in "brilliant", however the exact behavior here is customizable. As always, feedback is welcome. Thanks!

edit: Updated beta build if you feel like reviewing the new behavior. Thanks! https://github.com/johnlindquist/AceJump/releases/tag/3.0.0

[pkt-zer0]

@breandan: Have you considered making the old behaviour available behind a configuration option? Without needing to consider the "search" mode, there are more valid tags available, so you end up with fewer two-letter tags. If searching for single characters in "tags" mode is your preferred way of navigation, that becomes more convenient then.

[breandan]

@pkt-zer0 This is under consideration in #161 (although I think we can make both "modes" work together seamlessly by carefully allocating tags). Are you noticing missing tags in the latest version of AceJump? If so, please reopen #165.

[pkt-zer0]

No missing tags, that's fine. My question/problem was simply about "I have five tags on screen, why are they all two letters?". Which is not intuitive given the old behaviour, but makes sense in light of the "search" mode (the five tags were all attached to rather long words, making a lot of characters off-limits).

Thanks for linking to the relevant issue, I'll keep tabs on that.

[breandan]

Just to clarify, I believe we should expose configuration options for tagging behavior as mentioned above. We are making progress on that front, cf. #124, #28. I just want to ensure the plugin community does not get fragmented in the process.

As we currently have no unit tests, the testing process is basically me fiddling around with the plugin a bit before shipping. If we add a bunch of configuration options and modes, it would be much more difficult to test and catch certain bugs. Having proper tests (cf. #139) would make the whole process much more robust.