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

Labels of dynamic length #3

Open
postsolar opened this issue Nov 30, 2023 · 3 comments
Open

Labels of dynamic length #3

postsolar opened this issue Nov 30, 2023 · 3 comments
Labels
enhancement New feature or request
Milestone

Comments

@postsolar
Copy link
Owner

Currently labels can only be 2 characters long.
It wouldn't be hard to make labels' length dynamic.

Pros:

  • Would allow smaller sets of characters to be used for labels
  • Would guarantee we almost never run out of labels at zz

Cons:

  • Somewhat distracting — personally I like labels always and everywhere being the same length

Should be an opt-in feature perhaps.

@postsolar postsolar added this to the v0.2 milestone Nov 30, 2023
@postsolar postsolar added the enhancement New feature or request label Nov 30, 2023
@postsolar postsolar modified the milestones: v0.2, v0.3 Dec 5, 2023
@postsolar
Copy link
Owner Author

postsolar commented Dec 7, 2023

This raises a question of what to do when there are labels aa and aaa present — how to execute immediate jump? Possible solutions:

  • Only auto-execute the jump if there are no other candidate labels
  • Remove auto-executing the jump altogether, make it necessary to confirm input
  • Assess the number of labels to be generated and set static label length based on this number. So for a viewport which requires labels aa…zz there would only be 2-character labels, but for a viewport with more words there would only be 3-char labels aaa…zzz and no 2-char labels.
  • Some wacky algorithm which would skip over particular labels

Leaning towards option 3.

@postsolar
Copy link
Owner Author

Option 1:
➕ Will enable one-key jumps for the very few cases where the number of words is less than the number of characters allowed for use in labels
➖ More logic involved
➖ Inconsistent UI
➖ Tedious to almost always confirm the jump

Option 2:
➕ Very simple
➕ Only need to run labels interpreter script once
➖ Very tedious to always confirm the jump

Option 3:
➕ Will enable one-key jumps for the very few cases where the number of words is less than the number of characters allowed for use in labels
➕ Wouldn't change anything the majority of cases — i.e. those where just two characters are enough
➕ Still no need to confirm the jump
➖ Sometimes most labels would become one character longer just because there are a few extra labels which required an additional character

Option 4:
➕ Still no need to confirm the jump
➖ Complex logic of picking labels
➖ Labels start looking arbitrary and unpredictable — I tried this way in similar plugins and didn't like it

@postsolar
Copy link
Owner Author

Another issue is handling overlapping labels. With two-character labels this cannot occur because even if the word itself is 1-character long, there's still always a separating character (whitespace, etc), so no overlaps ever happen. One way to handle this for longer labels would be to only display the first 1 or 2 characters and then to display subsequent characters after the first one(s) was entered. I think that's how hop.nvim handles it. Personally I find it distracting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant