editor: Add generic navigation overlays

[GoldStrikeArch]

Closes #52629

Overview

Adds a generic editor-owned navigation overlay primitive for rendering target ranges, anchored labels, and fade ranges. This gives Helix amp jump, Beam Jump, and future jump-style features (like this one) a shared editor abstraction for overlay layout and paint instead of feature-specific render paths.

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content is consistent with the UI/UX checklist
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Release Notes:

• N/A

[formbook]

alexa, schedule a PR update on this for 2030

[ConradIrwin]

@GoldStrikeArch Does the inline version suffer from the problems described in the Helix PR?

My inclination would be to only ship the "above" version for now.

(We shouldn't have the display map learning about concepts like "BeamJump").

I'd expect this to be stored in the editor as a sorted Vec of struct NavigationTarget{anchor: Anchor, label: SharedString}, maybe with a color if needed (but happy to reuse the cursor color for now)

[GoldStrikeArch]

@ConradIrwin

Does the inline version suffer from the problems described in the Helix PR?

The only remaining problem is the monospace vs proportional fonts. It was not solved in this PR, everything else (like the "soft-wrap" and editor-width changes) were solved in this PR

(We shouldn't have the display map learning about concepts like "BeamJump").

I agree, I thought about making those keys purely dynamic

I'd expect this to be stored in the editor as a sorted Vec of struct NavigationTarget{anchor: Anchor, label: SharedString}, maybe with a color if needed (but happy to reuse the cursor color for now)

We will lose those things then:

• target outline/fill
• fade ranges
• TargetEnd / explicit anchors

[GoldStrikeArch]

@ConradIrwin FYI:

• this is how it looks with the Above rendering without any "advanced heuristics" to calculate whether or not we have the space to render a label "above the word"

• and this is how it looks like "with advanced heuristics":
  

So, IMO for the "Helix Amp Jump" feature it should be Inlined because otherwise the UX is not that good. You can compare it with the in-lined version here:

[ConradIrwin]

I was thinking we'd use the same approach as the hovered_cursors, they look something like this (old) screenshot:
, that way we can add text to the buffer without (hopefully) obscuring the content too much. Making the lines double spaced seems awful.

If that doesn't work, we have some support for creases/fold-indicators used by the [...] button for folds and the coding agent panel for file mentions - that should support replacing content inline without (too many) edge cases for non-monospace fonts.

Happy to play around more on Friday.

[meepleek]

Does the inline version suffer from the problems described in the Helix PR?
My inclination would be to only ship the "above" version for now.

I was thinking we'd use the same approach as the hovered_cursors, they look something like this (old) screenshot: <img alt="image" width="1544" height="624" src="https://private-user-images.githubusercontent.com/94272/574428582-a0aa4fd7-d169-45e3-a3a0-35b9f9ea1…, that way we can add text to the buffer without (hopefully) obscuring the content too much. Making the lines double spaced seems awful.

As a hx user - I'd prefer inlined hints for goto_word/similar because I'm already looking at the word I wanna jump to, so obscuring the text is really not an issue.
Also the view can be filled with hints when the view is packed with text (think prose), so putting the hints above the words sounds like it would hurt UX rather than improve it because it would make it visually unclear which hint maps to which word at a glance. If this ends up being configurable, that would be neat ofc, but after using this for a while inline hints seem like the easiest way to parse this (I'm biased ofc).

On a related note, thank you for working on this. It's exciting this might land in zed soon-ish 🙂

[GoldStrikeArch]

@ConradIrwin Hi, as per our session I adjusted this implementation to be a "bare minimum" for the Helix Amp Jump, now it is around 400 lines of changes and less test cases, wdyt?

[k-soomro]

Does the inline version suffer from the problems described in the Helix PR?
My inclination would be to only ship the "above" version for now.

I was thinking we'd use the same approach as the hovered_cursors, they look something like this (old) screenshot: <img alt="image" width="1544" height="624" src="https://private-user-images.githubusercontent.com/94272/574428582-a0aa4fd7-d169-45e3-a3a0-35b9f9ea1…, that way we can add text to the buffer without (hopefully) obscuring the content too much. Making the lines double spaced seems awful.

As a hx user - I'd prefer inlined hints for goto_word/similar because I'm already looking at the word I wanna jump to, so obscuring the text is really not an issue. Also the view can be filled with hints when the view is packed with text (think prose), so putting the hints above the words sounds like it would hurt UX rather than improve it because it would make it visually unclear which hint maps to which word at a glance. If this ends up being configurable, that would be neat ofc, but after using this for a while inline hints seem like the easiest way to parse this (I'm biased ofc).

On a related note, thank you for working on this. It's exciting this might land in zed soon-ish 🙂

Yes agree with this. I'm coming from flash.nvim/leap.nvim and overlaying the hints on the text is in fact less cognitive load and more user-friendly since I am usually staring right at the word I want to jump to so I don't have to shift my gaze to figure out the sequence of keys to jump to it.

[ConradIrwin]

Thanks. This is looking reasonable to me; want to merge this branch and with the helix one; then I can merge the feature.

[GoldStrikeArch]

@ConradIrwin

Thanks. This is looking reasonable to me; want to merge this branch and with the helix one; then I can merge the feature.

Alright, I resolved the merge conflicts and now it can be merged. Let's merge this PR and then I will adjust the Helix Amp Jump PR to use it (and we can re-iterate on it again if needed)

[k-soomro]

This is exciting. Does this mean this feature will be available in Zed soon?

[zed-industries-bot]

	Messages
📖	This PR includes links to the following GitHub Issues: #14801 If this PR aims to close an issue, please include a Closes #ISSUE line at the top of the PR body.

Generated by 🚫 dangerJS against f87516b

[GoldStrikeArch]

@ConradIrwin There were some issues with clippy (I fixed them), so can you please re-run the pipeline and then merge it once it is ready? I am not sure who can merge once the pipeline is done (I assume that only maintainers can do it)

[ConradIrwin]

Thanks!