Rewrite evil-ghostel from advice to command-remap architecture

[dakra]

Summary

• Replaces ~13 advice-add hooks on evil-* commands with evil-define-operator / evil-define-motion definitions bound via evil-ghostel-mode-map for normal and visual states (vterm-collection-style).
• Adds a public input-region API in ghostel.el (ghostel-input-start-point, ghostel-cursor-point, ghostel-cursor-row-end-point, ghostel-point-on-cursor-row-p, ghostel-point-in-input-p, ghostel-clamp-to-input, ghostel-goto-input-position, ghostel-delete-input-region, ghostel-replace-input-region) that integrations can build on. Lifts what was internal evil-ghostel--cursor-to-point / --delete-region / --meaningful-length into ghostel core.
• Drops the shadow-cursor model (and its two tests); the new operators read ghostel--cursor-pos directly each call and the existing sync-inhibit flag already covers the double-call scenarios the shadow was defending against.
• Operator-level clamp on forward overshoot — dw on the last input word no longer over-deletes into the blank renderer rows below the prompt. End-of-typed-input is detected by stripping trailing whitespace on the cursor row; works for shells without OSC 133.
• Forward word motions (w, W, e, E) clamped in normal state only so w from the last input word stays on the cursor row. Operator-pending state uses vanilla motions so dw / cw ranges can overshoot and get trimmed by the operator clamp.
• ghostel-goto-input-position includes vterm-style recovery for literal ^[[C echo (inner program doesn't interpret arrow keys) and for bash-autosuggest accept-on-right-arrow.

Test plan

• make -j4 all test-evil clean: 370 elisp + 173 native + 76 evil-ghostel tests, 0 unexpected, 2 unrelated skips, lint clean.
• New regression tests cover: dw-overshoot clamping (evil-ghostel-test-delete-word-on-last-word-clamps-overshoot), w-stays-on-input-row (evil-ghostel-test-forward-word-stops-at-input-end), w-falls-through-in-scrollback (evil-ghostel-test-forward-word-falls-through-off-cursor-row).
• Live-verified in a clean Emacs -Q against zsh -fi (no OSC 133): word word word<esc>bbcw → correct, w stays on cursor row, dw on last word deletes it, 0/^/$ work.
• @noctuid scenarios from Issues with evil single line movement/editing #246: please retest bbcw 3× consecutively in zsh and pi to confirm no regressions.

Notes for reviewers

• evil-ghostel.el ends up at 852 LOC vs evil-collection-vterm's 308. The delta is dominated by evil-ghostel--around-redraw (79 LOC — ghostel's renderer wipes the viewport region, vterm doesn't need this), the cursor↔point sync helpers (~50 LOC — viewport-row math), the insert-state-entry hook (45 LOC — vterm's cursor is the buffer cursor), and the three-way ESC routing (auto / terminal / evil).
• API stability: once exposed, the ghostel-* input-region functions become public contract.

[noctuid]

@dakra Thanks a lot. I didn't have time to test thoroughly. I'll test tomorrow but couldn't find any major problems with basic use. Here are two things:

• it should use remaps only, not bind any specific keys
• minor: word<esc>a (evil-ghostel-append) will add a visual space that isn't there (point will be after a space but backspace in insert would delete the "d"); test with evil-move-cursor-back nil and zsh (not sure if this is specific to my config, couldn't reproduce in bash)

[dakra]

@noctuid Thanks. I fixed the 2 bugs you mentioned.
I'll still have to have a closer look at it and test it more. but if you want to give it another test ride that's obviously helpful as well.

[noctuid]

I still haven't seen any more issues with editing/operators, though I'm seeing similar issues to the appending one. Sometimes the cursor will jump to the right side of the window when appending.

evil-forward-char can sometimes go many characters beyond the end of the text in the prompt line in normal state (e.g. in pi always and in zsh I can go right as far as I had previously typed text even if it was deleted). Same applies to e.g. 0/$.

I saw weird point warping a couple of times but can't reliably reproduce.

[AndiLavera]

Tested on aarch64-darwin, emacs 30, doom/evil latest with fish. Basic nav seems to be working.

I have the git branch justified right like:

~/.c/doom ❯❯❯ nslookup -type=txt on.quad9.net 2620:fe::9                                      main ✱

• I will place the insert cursor perfectly before the nslookup. A will place the insert cursor after the main ✱ until first keystroke.
• $ places my cursor on the ✱ in main ✱
• y$ will copy the main ✱

When I move out of a git repo, the main * in my terminal is gone:

~ ❯❯❯ nslookup -type=txt on.quad9.net 2620:fe::9

These bugs do not persist. A snaps directly after the 9, $ places the cursor on the 9, y$ copies only the written text and does not contain whitespace characters after the 9

[iftheshoefritz]

Is this intended to fix insert at cursor problems as well? Currently:

A 1234 ESC h h i 1 inserts the 1 at the end of the line after 4 instead of just after the first 1.

Also given ☁ ~ 12341, ^ takes me to the cloud in my prompt, not to the first character I have control over (1).

[dakra]

I experimented a bit with different versions today.
It's very fragile, I feel like every time I fixed one bug, another edge-case triggered and didn't work :(
Especially fish with a right_prompt was tricky.

But in my short testing it seems to work now.
Can you test again @AndiLavera @iftheshoefritz @noctuid ?

[noctuid]

@dakra Is this PR being canceled or replaced?

[dakra]

@noctuid oh. I was doing some housekeeping in magit of git-refs and deleted a bunch of old branches.
This one was not supposed to be in there, sorry 🙈

[iftheshoefritz]

None of these are fixed:

A 1234 ESC h h i 1 inserts the 1 at the end of the line after 4 instead of just after the first 1.

Also given ☁  ~  12341, ^ takes me to the cloud in my prompt, not to the first character I have control over (1).

[iftheshoefritz]

Also a weird one: typing f flickers the cursor briefly to the position just before as the letter appears. This doesn't happen for any other character in the (English) alphabet.

[dakra]

A 1234 ESC h h i 1 inserts the 1 at the end of the line after 4 instead of just after the first 1.

that works for me.
Do you have the latest version? I rebased, so you have to do a git hard reset.

Also given ☁ ~ 12341, ^ takes me to the cloud in my prompt, not to the first character I have control over (1).

Do you have shell integration on?
What shell are you using?