AceJump
AceJump copied to clipboard
Tag placement and visibility improvements
Is your feature request related to a problem? Please describe. Frustrating when the jump hints are translucent as it makes hint very hard to see. Also I dont find the green hints very useful, I use vimium in the browser and find that it's best to be minimal. Usually I'm not intending to be super precise and just want to jump to an area and then adjust with h+j+k+l
Describe the solution you'd like There should be an option to make all hints have full opacity. Id even argue that there should be an option to turn off the green hints as well, so you can have: only full opacity yellow hints
These would be optional and therefore not affect the core functionality.
Additional context Here is a picture of what I mean, as you can see hints like JJ and R are clear but those of GG and FF are harder to see (when you view the editor at fullscreen and not zoomed in like it is here) and IMO the green hints just get in the way and don't provide any benefits (its useful to know what you've typed but id argue the cons are at least equal to or greater):

Related to #228, #227. We should probably avoid painting adjacent characters. Agree that it would be nice to make the opacity/placement customizable. Text highlight color is already customizable, but the opacity rules for proceeding tags are not clear. By default, we try to always place tags to the left of the match, except if it is the first character of the line or would overlap with another tag location.
One solution is to always paint tags to the left of the match location at full opacity and enforce a minimum tag separation. The only issue is, I'm not sure how to paint tags to the left of the first character on a line in the editor window. If anyone wants to try solving this, here is the current implementation:
https://github.com/acejump/AceJump/blob/1800efd60dc6af988b884bcfa0f4fdfd4fc20c30/src/main/kotlin/org/acejump/view/Marker.kt#L165-L166
Do you mean left or right? I ask because the tags with <1 opacity are all on the right of the location. Is it also possible to turn off green tags?
I could jump in, but I've no experience with Kotlin dev and so wouldn't likely produce good results in a short timeframe, if anyone can give it a shot that'd be great, if not i'll try in free time when able, is this the best place to start?
AceJump always paints tags to left, except (1) when it is the first character of a line or (2) overlaps with an existing tag. In these cases, it paints tags to the right of the match with transparency so that users can to see the text if they want to continue typing. Tag locations are tracked by Canvas
:
https://github.com/acejump/AceJump/blob/1800efd60dc6af988b884bcfa0f4fdfd4fc20c30/src/main/kotlin/org/acejump/view/Canvas.kt#L58-L61
The green boxes are not tags, but RangeHighlighters
, which are rendered beneath the editor text:
https://github.com/acejump/AceJump/blob/d70f6939d558da4aafde6f6e50a880aa3f76512e/src/main/kotlin/org/acejump/view/Marker.kt#L105
Essentially, this is the same mechanism the Find dialog (Ctrl/Cmd+F) uses to highlight text. Tags are rendered using a different mechanism, which paints above the editor text:
https://github.com/acejump/AceJump/blob/d70f6939d558da4aafde6f6e50a880aa3f76512e/src/main/kotlin/org/acejump/view/Marker.kt#L143
It is already possible to customize the highlight color via Settings
> AceJump
> "Text highlight color". If you don't want to see any highlights, you could set it to match the editor background color.
Is this the best place to start?
Yes, more than happy to accept PRs. The simplest solution is probably to always paint tags to the left at full opacity and skip matches which are directly adjacent. Feel free to open a PR and tag this issue. Don't hesitate to ask if you have any questions!
Why does it only put my tag on the same line, while in the screenshot, it will place the tag above if the line is empty?
@Ciel-MC Thanks for pointing this out. The tag placement rules were most likely lost during one of the multiple rewrites over the years, however we should restore the original behavior to not occlude adjacent text. I would like to reimplement this but do not have the bandwidth at present. PRs are highly welcome!