make cursor_trail work on the same command prompt only

[xuhdev]

Is your feature request related to a problem? Please describe.

Currently cursor_trail always shows cursor movement once the distance is beyond a certain threshold.

However, in most cases when the cursor makes a big movement, my eyes either know where
it will land or don't care. For example,

• After typing in a long command and pressing "Enter", I know it will show up in the next command line prompt.
• When a program outputs long segments of text, I don't care where the cursor is.

However, the unnecessary animation in these scenarios is distractive.

The moments I see cursor_trail is only needed when I move cursor within a prompt
buffer. For example, I may press Alt-F to jump a word, and the word has an
unknown length to my eyes until I look carefully.

I tried to adjust cursor_trail_start_threshold and cursor_trail_decay, but
they don't seem to be able to address the problem.

Describe the solution you'd like
Add a new option cursor_trail_scenario to specify when to enable cursor
movement.

[kovidgoyal]

@jinhwanlazy please review.

[jinhwanlazy]

While I understand what you're trying to achieve, I'm not sure if we can reliably implement this because the terminal doesn't know the semantics of the movement.

Technically we could detect whether a cursor movement was triggered by a control sequence (like a newline character) versus direct cursor positioning commands, the behavior would vary in many applications and I think it would look even more annoying.

[xuhdev]

Sorry I didn't write the code. It's a feature request and it's a bot that wrote the changes...

[kovidgoyal]

@jinhwanlazy I think the OP is asking that when the main screen is active and the cursor is in an output region the trail be suppressed. This can be detected fairly reliably at least for shells that implement shell integration. However it will break for shells that dont implement it. Basically the logic would be something like, if the last prompt marking command indicates we are in output mode and the main screen is active, suppress the trail otherwise keep it on. And if no prompt marks are received keep it on. I dont use trails so I am not the right person to comment on how well it works, but that is how I would approach this.

[jinhwanlazy]

if the last prompt marking command indicates we are in output mode

Can you tell me where I should look for this?

[kovidgoyal]

On Wed, Dec 25, 2024 at 08:15:23PM -0800, Jinhwan Choi wrote: > if the last prompt marking command indicates we are in output mode Can you tell me where I should look for this?

See screen_cursor_at_a_shell_prompt() You probably want a slightly different function that returns -2 for UNKNOWN_PROMPT_KIND. You can probably change that function to do that, check its call sites to make sure its safe, if not write a new function.