feat: support setWorkingMessage in RPC mode

[erwagasore]

Context

I'm writing a pi extension (peculiars) that shows witty context-aware status messages as the agent works — different quips for reading files, running commands, editing, thinking, etc.

The extension uses two APIs for maximum coverage:

• ctx.ui.setWorkingMessage(text) — replaces the working indicator (designed for exactly this use case)
• ctx.ui.setStatus(key, text) — persistent footer/header status

Problem

In the Emacs RPC client, setWorkingMessage falls through to the unsupported method handler in pi-coding-agent--handle-extension-ui-request:

(pcase method
  ("notify"         ...)
  ("confirm"        ...)
  ("select"         ...)
  ("input"          ...)
  ("set_editor_text" ...)
  ("setStatus"      ...)
  (_                (pi-coding-agent--extension-ui-unsupported event proc)))

setStatus works and shows in the header-line after the │ separator, but that position feels disconnected from the spinner — the natural home for working messages.

Suggestion

Add a setWorkingMessage handler that displays the text adjacent to the braille spinner in the header-line. When the message is cleared (setWorkingMessage() with no arg), it reverts to the default spinner-only display.

Something like:

("setWorkingMessage"
 (let ((text (plist-get event :message)))
   (setq pi-coding-agent--working-message text)
   (force-mode-line-update t)))

Then in pi-coding-agent--header-line-string, after status-str:

(when pi-coding-agent--working-message
  (concat " " (propertize pi-coding-agent--working-message
                           'face 'pi-coding-agent-retry-notice)))

This would give the layout:

Sonnet 4 • high ⠹ 📖 Skimming through the source…  42 msgs (65%)

Current workaround

Using setStatus which works but places the text after stats:

Sonnet 4 • high ⠹  42 msgs (65%) │ 📖 Skimming through the source…

Thanks for the great Emacs integration!

[dnouri]

Thanks for the nice issue description. I'm already curious to try your extension! :-)

I had some thoughts about replacing the spinner with something else that indicates what the model is doing right now. Closed #101 for now though since it was stale. Still wortwhile comparing notes I think:

• Do we like the idea of having (thinking/replying/running/compact.)
• If we like it, would we want setWorkingMessage to replace that? (Where does that show up in the Pi TUI?)
• In Replace braille spinner with semantic activity status #101, I thought it was a good idea to keep the length of the text static, to avoid having large parts of the header-line jump around. That would actually be an argument for putting it where setStatus lands, after the stats. Which perhaps defeats the purpose: to have two handlers write to basically the same area.

Your thoughts?

[dnouri]

@erwagasore So I was able to look into this issue a little bit more:

It appears that setWorkingMessage is a no-op right now in rpc-mode.ts in upstream. I started work on a PR to pi-mono that would wire it up, the same way that setStatus works essentially. That PR will include other improvements to the rpc mode (for instance /tree support!), so it might take a little bit for it be merged. I'll link the PR in this issue once we're there.

In the meantime of course you can do what you said, emit setStatus instead, do I understand that you want to use both interfaces and want to have it where setWorkingMessage puts the info. Maybe there's a way to sniff and see if you're in rpc mode or not, and then use those two selectively.

We'll still have to fight over where it'll go in Emacs. Seems a bit redundant to be honest if both of status and working message end up in the same space, but I guess maybe fine.