Tag string is not displayed

[sasensi]

Describe the bug Under certain circumstances, the tag string (characters that we should type to jump) is not displayed. Note that the tag itself is still visible.

To Reproduce Steps to reproduce the behavior:

1. Open a file containing the following content:

aaaaaaaaCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789

2. Invoke AceJump in jump mode
3. Type "c"
4. 2 tags are displayed as expected, for "C" and "c" but the string of the "C" one is not displayed

**Expected behavior**
The string should be displayed.

**Screenshots**

https://user-images.githubusercontent.com/11247504/113502590-886f6200-952d-11eb-8b71-519e6eb694f3.mp4

**Desktop (please complete the following information):**
 - OS: Windows 10
- IDE and version: PHPStorm 2020.1
- AceJump version: 3.7

[breandan]

@chylex

[chylex]

The line contains every possible tag character, so it's only possible to tag the second one with A or B because they preceed it. Otherwise there could be a conflict with a tag if you continued typing the rest of the line. In these situations you can still use Enter to navigate to the search result and then Escape to cancel and keep your caret there.

Maybe it would be good to add an option for "maximum query length" since it's unlikely anyone will actually type more than a few characters in the query? I think as long as it's configurable and somehow made obvious in the UI that you can only type a certain max amount of characters before you have to type the tag, it won't be confusing.

[breandan]

Due to the limited number of assignable tags, there is always an implicit maximum query length, however it is usually much longer than the length of a line of source code. It would probably be a good idea to make this explicit. Although the example given above is possible to assign unambiguously with two-character tags, ex. we could assign DF to the first match because DF is not located anywhere else in the text. A file containing all alphanumeric bigrams is extremely unlikely to occur in practice. Here is the sequence I am imagining:

aaaCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789

C → a[DF]{C}DEFGHIJKLMNOPQRSTUVWXYZa[B]{c}defghijklmnopqrstuvwxyz0123456789

D → a[D|F]{CD}EFGHIJKLMNOPQRSTUVWXYZab[B]{cd}efghijklmnopqrstuvwxyz0123456789*

E → a[DF]{CDE}FGHIJKLMNOPQRSTUVWXYZa[B]{cde}fghijklmnopqrstuvwxyz0123456789

D → aa[D|F]{CDE}FGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789

F → aaa|CDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789

∗ This behavior would require us not to immediately discard the first character when a tag is partially selected as we discussed here.

This solution is probably more trouble than it's worth, so setting the MQL seems reasonable. Another solution is to just close this issue and say "works as intended".

[chylex]

I didn't even consider that possibility, it would be quite neat, but as you said not sure if it's worth the effort. Discarding the first characters is just visual, it should be possible to revert back to the original behavior of highlighting the first tag character in any case - unless I'm misunderstanding the issue?

[breandan]

Although discarding the first character after partial tag selection may just be cosmetic, keeping it visible and highlighted is an important visual cue when partial selection may coincide with another substring. This scenario occurs when tags are highly constrained like the above example. If we just consider the example [D|F]{cd}...[B]{cd}, this strategy would allow us to assign tags without setting an MQL. As you mentioned, it is probably not worth the effort, since (1) we are already resetting the query on word boundaries, (2) such scenarios are relatively uncommon, and (3) the user can still use Enter or Shift+Enter to select untagged sites.