wezterm icon indicating copy to clipboard operation
wezterm copied to clipboard

Cursor trail

Open flowchartsman opened this issue 2 weeks ago • 1 comments

Initial cursor trail implementation based off of Kitty's

sample config:

local config = {}

config.cursor_trail = {
  enabled = true,
  -- dwell_threshold controls the amount of time the cursor must sit still
  -- to draw a trail.
  dwell_threshold = 80,
  -- distance_threshold defines the radius in cells the cursor must jump before
  -- a trail is drawn.
  distance_threshold = 5,
  -- duration is the animation time in milliseconds for leading edges of the trail to reach the cursor
  duration = 300,
  -- spread is a multiplier for duration applied to the trailing edges of the quad used to render the trail. This increases the apparent smear.
  spread = 2,
  opacity = 0.6,
}
config.animation_fps = 60

return config

closes #7387

NOTE: Given the discussion in #1136, #1432 and elsewhere, I'm leaving this PR as a draft and a discussion piece for now, since it effectively reduces cosmetic animations to a single effect with a very specific configuration, and would make the process of migrating to a more general approach more difficult if that's the direction the project wants to go.

flowchartsman avatar Dec 07 '25 22:12 flowchartsman

@wez or any other contributors: feel free to chime in if this is way off-base.

There are definitely some rough edges that need sanded down even now (hence the draft), and if a complete gutting or rewrite is required, it won't hurt my feelings.

flowchartsman avatar Dec 07 '25 22:12 flowchartsman

will this capability be released in new release version?

zhecks avatar Dec 16 '25 13:12 zhecks

will this capability be released in new release version?

If it gets merged, then yes I guess, subscribe to this PR to get notified

bew avatar Dec 16 '25 16:12 bew

Maybe affected by my running it on old laptop with integrated graphics, but, using the suggested settings above, to my eyes, the cursor itself immediately jumps, with the trail following behind:

https://github.com/user-attachments/assets/c3e3d97c-5f93-4f99-ad3b-864dc75ccc63

I have a sense that kitty's cursor takes a moment to appear in the new position, creating more of an impression (to my eye) of movement:

https://github.com/user-attachments/assets/1d6d7edb-248b-455e-aa42-426be48350c1

Maybe my computer or eyes are off, I'm not sure.

But wondering if there's a way to delay the display of the cursor in the new position (turn it invisible? change it to the background colour?)

In any case, very cool work!

emacsomancer avatar Dec 17 '25 02:12 emacsomancer

Maybe affected by my running it on old laptop with integrated graphics, but, using the suggested settings above, to my eyes, the cursor itself immediately jumps, with the trail following behind:

This is probably a combination of a couple factors. First would be the dwell time, which exists to keep the trail from spasmodically jumping around on every small cursor hop, since there is no way in Wezterm that I could find to distinguish cursor movement driven by user input from that which happens as a consequence of command output or by direct repositioning. [N]vim, for example, tends to briefly hop the cursor to the upper left of the terminal before the TUI is rendered and it finds its home in the editor window. Without a dwell time, you'd see a distracting series of hops every time it started. So, instead, the animation only starts after the cursor has not moved for a moment, which might contribute to the perception of lag. Maybe try lowering the dwell time a little and see if that changes your perception. It's a bit of a hack, and I'm not entirely satisfied with it.

The other factor is probably a consequence of how the animation is rendered: the quad used to draw the trail is initialized in the position of the most recent "significant" jump and with the same dimensions as a block cursor. Then the animation code starts to interpolate the vertices towards their destination. The "leading" edge transitions more quickly than the trailing edge to create the effect, but it still needs to transit the entire distance. If the leading edge were instead initialized at the destination (or some fraction of the distance thereto), that might decrease the perception of lag. I'll play around with it some, but I'm reluctant to add it as another setting. Overall, my preference is to find some satisfying combination of settings and then just hard code them, rather than provide too many knobs to twiddle.

flowchartsman avatar Dec 17 '25 03:12 flowchartsman