Cursor goes up with output in pi coding agent in normal state

[noctuid]

While there is output happening, the point goes up with the output instead of staying in the prompt in evil normal state. If in insert state, it will stay in the prompt line correctly. I would expect it to stay in place in normal state if in the prompt line or below it if that's possible.

[Cianidos]

Reading this together with #218, I think we may be seeing two valid but different Evil terminal workflows.

My own workflow is navigation-first: I use emacs/insert state for terminal input, and normal state as a buffer/navigation/copy state. From that perspective, preserving point in normal state during redraws is desirable.

But #228 sounds like a tracked-input workflow: normal state is still expected to stay attached to the live prompt/input area, and point should follow the terminal cursor unless the user intentionally navigates away.

Both expectations seem reasonable, but they imply different behavior. A fix for one can easily feel like a regression for the other. Maybe evil-ghostel needs to document this distinction explicitly, and possibly expose a small policy option for normal-state behavior:

evil-ghostel-normal-state-behavior
;; 'navigation   normal state preserves point; terminal input is handled in emacs/insert
;; 'tracked      normal state follows live terminal cursor/input where possible
;; 'hybrid       follow terminal cursor until user navigates into scrollback

That would also make the README contract clearer: PTY-backed normal-state editing could be described as best-effort for the tracked-input workflow, not as something guaranteed for all terminal/TUI states.

[Cianidos]

Small update from my side after testing locally.

I disabled evil-ghostel-mode and kept plain Evil in ghostel-mode, with ghostel-mode starting in emacs state. Then I added only a small local advice around ghostel--redraw to preserve point in Evil normal/visual/motion states.

That gives me exactly the workflow I wanted: terminal input is terminal-owned in emacs state, while normal state is detached navigation/copy over the rendered buffer during live output. I do not need PTY-backed normal-state editing commands.

So my comments above should probably be read as feedback from the navigation-first workflow, not as an argument against the tracked-input workflow requested here. For users who want normal-state editing to operate on the live prompt, evil-ghostel-mode still seems like the right place for that.

This also makes me think the two concerns could be documented separately:

1. point preservation / navigation behavior during redraws
2. PTY-backed Evil editing and cursor synchronization

No need to block this issue on my workflow; I mostly wanted to share the local finding because it helped clarify the distinction.

[noctuid]

I think there is no use case where users would want the point to go from at shell prompt or cli harness prompt to above it just because they switched to normal state while output was happening.

The behavior in vterm I think is the sane default. The point stays in the shell prompt even in normal state. If you want to be able to navigate/copy while new input is coming in, you enter vterm-copy-mode.

[dakra]

@noctuid I changed it so that when you're in normal-mode and you're in the current prompt line it stays with the output, but when you move away it stays where you moved.
Can you check if that fixes your problem?

It's basically @Cianidos 'hybrid suggestion. I didn't implement a toggle for now. But I'm open for PRs or more discussion.
This was a relative simple fix and also independent of the multiline problem in #218 so I thought this is easy to close this way.

[noctuid]

@dakra Many thanks. I have no need for it to be configurable personally. This works well enough. The only nitpick I have is that it could consider the prompt line and also anything below it, but that's an edge case I don't care too much about.

[noctuid]

@dakra Is there some new setting related to this behavior, or is it broken again?

[dakra]

@noctuid it was a regression.
Should be fixed on main.
I made an additional fix so moving the cursor away on the prompt line also keeps the scroll anchor.
Please test.

[noctuid]

Yes, it's fixed now, thank you