chat mode: `<up>` skips the first line of a multi-line prompt draft

[OSadovy]

Checklist

• I agree to communicate with the author myself (not AI-generated).
• I've read the README's Filing issues section.
• I'm running the latest versions (fill in below).
  • agent-shell version: 0.73.4
  • acp.el version: 20260803.2034
  • ACP package (e.g. claude-agent-acp) version: claude-agent-acp 0.70.0
  • Agent CLI (e.g. claude, gemini) version: claude 2.1.234
• For requesting new agent support, I'm including a link to the ACP-capable agent or related ACP package.
• For issues, I'm including ACP traffic (as per README).

Reproduced on 0.73.4; the code path below is unchanged in main (0.74.2).

Steps to reproduce

1. Start an agent shell, send a prompt, wait for the response.
2. At the prompt, type:

   first line
   
   second line
   

3. C-a on second line, then <up> <up>.

Expected: the blank line, then first line.

Actual: the blank line, then the end of the agent's last response line. first line is not reachable with <up> at any goal column.

Cause

agent-shell-chat-mode.el:297

(start (if keep-term (1+ raw-start) raw-start))

There are two newlines between a response and the prompt. keep-term gives back one — the response's terminator — but the second one terminates the blank line, and stays covered. That blank line is then wholly inside the Me overlay's display "" run, so it has no screen presence.

adjust_point_for_property will not leave point inside such a run, and for an empty display string moving backward it goes to beg - 1: the character before the whole run, which is the end of the response line two lines up.

Same reasoning as the comment at line 283, one newline further along.

agent-shell-chat-me-keeps-response-terminator-test inserts the real "\n\n" layout but only asserts the first terminator is uncovered, so it passes either way.

Possible fix direction

Starting the Me overlay at the prompt's line-beginning-position would keep the blank line a real line.

That alone would let surplus blank lines through — across 8 shells here the overlay covers 1, 3 and 6 newlines — so collapsing the surplus may want a separate run above the kept blank line rather than extending this one.

[OSadovy]

b4b914a fixes the original symptom — <up> reaches the first line of a
multi-line draft now. But moving the marker into line-prefix trips something
else, so I'd hold off closing this.

If the draft wraps onto a second screen row, the first <up> that crosses from
a continuation row back into the prompt's own first row signals
beginning-of-buffer. Point still moves one row, correctly — the error is
spurious. It's one press and then everything behaves normally, which is why
it's easy to miss.

The cause is vertical-motion under-reporting. On the Me overlay the prompt
text carries display "" while the marker rides line-prefix. With both on
the same line, moving up out of the first continuation row moves point but
returns 0 instead of -1, and line-move-visual reads that as hitting the
buffer edge:

(and (< arg 0)
     (<= (vertical-motion (cons ... arg)) arg))

emacs -Q, no agent-shell, Emacs 30.2:

(progn
  (switch-to-buffer (get-buffer-create "*repro*"))
  (erase-buffer) (remove-overlays)
  (insert "a line above\n\n")
  (let ((start (point)))
    (insert "Claude> " (make-string 150 ?x))
    (let ((o (make-overlay start (+ start 8))))
      (overlay-put o 'display "")
      (overlay-put o 'line-prefix "  > ")
      (overlay-put o 'wrap-prefix "  > ")))
  (delete-other-windows)
  (split-window-right 60)
  (goto-char (point-max))
  (beginning-of-line)
  (vertical-motion 1))

That leaves point on the first continuation row. Press <up>: point moves up a
row and you get "Beginning of buffer".

Neither property does it alone — display "" on its own is fine, a
line-prefix on its own is fine, and the Me label above is irrelevant.
invisible t in place of display "" behaves the same, so it isn't specific
to display. Emptying the wrap-prefix doesn't help either; it's the
line-prefix that matters.

One shape that does clear it is keeping the marker in the display string rather
than the margin:

(overlay-put o 'display "  > ")
(overlay-put o 'wrap-prefix "    ")

Same buffer, same wrap, no signal. I've only checked that much, though — I
haven't checked it against the multi-line case this issue started with, so
treat it as a lead rather than a patch.