Feature: Expose token level hover actions, similar to what we have now for lines

[ShpetimA]

Prerequisites

• I have searched for duplicate or closed feature requests
• I have read the contributing guidelines

Proposal

I would like to have token based hover actions on top of the line level ones that we have atm.

For example something like:
onTokenEnter
onTokenLeave
onTokenClick

I have a fork of the feature here https://github.com/ShpetimA/pierre/tree/pierre-token , I was curious if you guys would add something like this in the future or I could even create a pr for this.

Screen.Recording.2026-03-25.at.7.07.24.PM.mov

Motivation and context

Lsp integration with annotation (have):

The reason why I want this feature is because atm I'm working on a local code reviewing tool and I'm starting to add lsp support on top, atm with the current api I can only add annotations which are good for showing diagnostic information :

Additional lsp actions (missing):

But as additional features I also want to add lsp information on hover like showing type definitions, gtd gtr etc. To achieve this I need these new onToken callbacks or something to that extent.

[amadeus]

this is def something we'd like to add at some point. I'd be curious to see what sorta code stuff you did to accomplish this, if you can share the specific commits/etc from your fork.

[ShpetimA]

764e243 its one big commit here, basically the idea was on shiki highlighting transformer to add data-properties which tell us the start and end of tokens

Which we could then use in the InteractionsManager to recover that dom data on pointer movement.

[amadeus]

Interesting. Do you have any benchmarks on how much overhead this adds to highlighting?

If we do something like this, we'd probably want to make it opt in

[ShpetimA]

I was thinking along the same lines since shiki is kindof optin in in ofitself. For benchmarking no i haven't done any just from eyballing it doesn't seem like its adding alot of overhead. But I could do proper benchmarking and get back to you if intrested

[amadeus]

ooki yeah, def interested in this as something we should add. A couple high level thoughts if you're willing to adapt that commit a bit to a PR, we can talk through things there.

A couple initial notes on what I think should probably happen (my first pass thinking about it, open to feedback/discussion)

1. Ideally we only apply this transform if you opt in
   a. if you're using a worker pool, it should be an additional render option (not sure a good name that field yet, but probably a boolean prop, worker pool is always an all or nothing type situation with the render options)
   b. This same option should exist on DiffHunksRenderer and FileRenderer
   c. If you aren't using a worker pool, File/FileDiff should probably set this prop on their respective renderers based on the existence of onTokenEnter, onTokenLeave, or onTokenClick
2. I haven't fully reviewed what you wrote for the InteractionManager yet, but the main thing to be aware of there is if no token events are added, we should avoid doing any dom work there (maybe it's already doing that, just logging this as a note for consistency stuff)

If this is something you're interested in adapting, feel free to open a PR for it, and we can go from there 🙏

[ShpetimA]

Yes im down, probably will open a pr on the weekends since im more free then, will clean up the code and take the feedback into count. I created a script for benchmarking with gpt5.4 on the background using the parseMergeConflict as base on the fileConflictLarge doesn't add that much overhead

[amadeus]

ye no problem, thanks for bringing this up with a clear and clean implementation!

[ShpetimA]

@amadeus Created a pr for this, atm its without the boolean flag that we discussed I tried adding it, but was also trying to make typescript throw errors in case you pass while having this disabled. Adding these types im not liking it atm so wanted to confirm first with you if we should do this. Since shiki transforming doesn't seem to add overhead and the token actions aswell so would it be worth or nescessary to do this ?

type TokenInteractionOptions<TMode extends InteractionManagerMode> =
  | {
      enableTokenInteractivity?: false;
      onTokenClick?: never;
      onTokenEnter?: never;
      onTokenLeave?: never;
    }
  | {
      enableTokenInteractivity?: true;
      onTokenClick?: InteractionManagerBaseOptions<TMode>['onTokenClick'];
      onTokenEnter?: InteractionManagerBaseOptions<TMode>['onTokenEnter'];
      onTokenLeave?: InteractionManagerBaseOptions<TMode>['onTokenLeave'];
    };

[amadeus]

Sorry, that's probably on me for not describing it well. I don't think we should have a specific boolean prop for it on interaction manager, just that interaction manager should only do the setup work if any of those handlers exist, if that helps? I have a few things to do today, but i can probably look closer at your PR later tonight

[ShpetimA]

No problem whenever you have time take a look. There are alot of linechanges because of the snapshot diffs i got scared at first when i saw the pr changes hahahah. For the boolean prop I understand what you mean my only issue is if we do have that boolean like for example enableTokenInteractivity on worker pool level then I think in that case we should disable the onTokenClick etc types on FileDiff props. Doing this I felt like I was touching alot of the types and wanted to get your thoughts on it but look at the pr first and we can discuss this part.

[amadeus]

Thanks again for the help on this, this is officially shipped in v1.1.9