Evil multi-line issues in pi

[noctuid]

Evil support does not appear to work with multi-line editing in pi (haven't tried other tui programs but could be the same). For example, inserting a couple newlines, entering normal state and going up to the first line, then pressing dd will delete the last line not the current line.

[dakra]

Can you try the PR #222 ?
I'm not an evil user so my testing was very limited.

[noctuid]

Thank you, seems improved but still quite a lot of issues, e.g. evil-open-below and evil-open-above don't work correctly. Going up lines and then running evil-append-line puts the cursor at a later line. Same for evil-insert-line. C will delete the last line it seems as well.

[dakra]

@Cianidos do you mind to have a look at this?

As I don't use evil it's always a bit of a pain for me to try to reproduce and fix those issues.

[noctuid]

Multi-line editing is not a huge priority for me since I can compose longer prompts in a separate buffer and send them to ghostel. The single line editing also has some issues though, e.g. evil-beginning-of-visual-line and evil-beginning-of-line appear to not work in insert state (and the end equivalents).

[dakra]

@noctuid ok. maybe you want to give it a shot for a PR? You can base it from my PR here if that helps (or not of course)

[Cianidos]

I want to clarify the intended contract for evil-ghostel here.

@noctuid, do I understand your expectation correctly: normal-state editing commands such as d, c, r, p, etc. should work against the live terminal input by being translated into PTY key sequences?

@dakra, I noticed that the README currently documents this as supported behavior:

• delete/change/replace/paste are listed as normal-state operations handled by evil-ghostel
• insert/append sync the terminal cursor to point before entering insert state
• alt-screen programs are described as unaffected

Was that README section meant as the deliberate supported UX contract for evil-ghostel, or did it grow out of the implementation and maybe now needs to be reconsidered?

The reason I ask is that, in practice, this contract seems very hard to make robust for arbitrary terminal programs. Ghostel can move the terminal cursor only by sending key sequences to the PTY, but the running program owns the real input state. For shells/readline this may be manageable, but TUIs can have input fields, modal state, cursor constraints, wrapped prompts, padding, and application-specific key handling. In those cases, translating Evil buffer edits into PTY actions seems fragile and likely to have many corner cases.

My personal expectation is closer to treating Evil normal state as navigation/copy mode. One of the main reasons I use a terminal inside Emacs is that I can freely navigate, search, select, and copy from scrollback like in other Emacs buffers. I usually stay in Emacs/insert state for terminal input, then switch to normal state when I want to navigate the buffer. From that perspective, editing inside a TUI input field is mainly the TUI application's responsibility; if a larger editor is needed, configuring $EDITOR to emacsclient feels like the more reliable path.

So I think there are two separate questions:

1. Is the current README contract still the intended direction?
2. If yes, this issue is a bug in that contract. If no, maybe the contract should be narrowed, for example making normal state explicitly navigation/copy-oriented and read-only with respect to the PTY.

That is only my preference, though. It would be useful to hear what UX other Evil users expect here.

[dakra]

@Cianidos thanks for looking into it ❤️

I think the - Alt-screen programs (vim, less, htop) are unaffected part in the readme is probably confusing
and we should scratch that. I read it as in insert-mode they work as expected.
But you're right that in normal mode it get's wired as they control the input field (or even multiple input fields).

I agree with you that I don't really see a reason to navigate away from the prompt/input field to make edits, that doesn't make much sense but I'm also not an evil user.
I do think that if there is a possibility to support editing commands from normal mode, we should try our best
to do the right thing. And the multiline issue with Pi here for example sounds like something that should
be solvable. Note that pi is like claude not an alt-screen app, so in theory we should be able to handle it with sending cursor keys and X-times backspace etc.

But then again, I don't use evil and I don't now how well it works with eat, vterm or term.el.
All evil-ghostel code are the least reviewed and least tested bits from my site.
I mainly added it because many people asked for it.

I'm open to any PRs, be it code or only readme clarifications.

[noctuid]

I don't have much to add other than to say that vterm is buggy for multiline input in pi also, but it doesn't have the single line issues that I mentioned for ghostel.