Display qualifier key binding help in text style header

[bcc32]

Previously, the qualifier (e.g., "[1/5][Edit]") and key binding hints
(e.g., "C-c C-c Submit") were only rendered in graphical-style headers.
This meant that users with agent-shell-header-style set to 'text would
not see any key documentation in the header line.

Checklist

• I agree to communicate (PR description and comments) with the author myself (not AI-generated).
• I've reviewed all code in PR myself and will vouch for its quality.
• I've read and followed the Contributing guidelines.
• I've filed a feature request/discussion for a new feature.
• I've added tests where applicable.
• I've updated documentation where necessary.
• I've run M-x checkdoc and M-x byte-compile-file.

[xenodium]

Thanks for the PR!

I'm a viewport and graphical header user myself. Been trialing the text header to see if I'd swap more permanently and also noticed it needs to catch up with graphical. Thanks for kicking this off.

AFAIK, the text header has a single-line rendering limitation, or do you have additional settings? In most instances, a large chunk of the single-line text header is likely going to be hidden unless the window is large enough. The proposal currently looks as follows for me:

I'm thinking we may need to get a little creative with the text header line to compact things in. Here are some ideas.

1. States

For example:

[2/2][View] Claude ➤ Default (recommended) ➤ Default @ project ➤ 23k/1m (2%) ➤ [?] Help

pressing [h] switches header to:

[2/2][View] Claude ➤ [n] Next [p] Previous [r] Reply [h] Next [h] Next

2. Transient

[2/2][View] Claude ➤ Default (recommended) ➤ Default @ project ➤ 23k/1m (2%) ➤ [?] Help

pressing [h] opens agent-shell-viewport-help-menu.

3. Split between header and mode line

See if we can potentially split information and render some of it in the header and remaining in mode line.

It's hard to tell which one of these would work out best in practice unless we try them out. I understand this may be more than you had originally signed up for in the PR, so I'm happy to play with the alternatives if you prefer to defer the work.

ps. Kinda glad you ran into this bug ;) It tells me there are folks out there using the viewport interaction. I have a feeling there are only a few of us.

[bcc32]

Thanks for these suggestions!

AFAIK, the text header has a single-line rendering limitation, or do you have additional settings?

No, indeed, just a single line. I agree it can get pretty crowded.

In most instances, a large chunk of the single-line text header is likely going to be hidden unless the window is large enough. The proposal currently looks as follows for me:

I'm thinking we may need to get a little creative with the text header line to compact things in. Here are some ideas.

1. States

For example:

[2/2][View] Claude ➤ Default (recommended) ➤ Default @ project ➤ 23k/1m (2%) ➤ [?] Help

pressing [h] switches header to:

[2/2][View] Claude ➤ [n] Next [p] Previous [r] Reply [h] Next [h] Next

I think it might be a bit too precedent-breaking to have the header line be stateful in this way.
I guess it's somewhat analogous to how which-key-mode works, but in any case I think it's not
the ideal way for this to work.

2. Transient

[2/2][View] Claude ➤ Default (recommended) ➤ Default @ project ➤ 23k/1m (2%) ➤ [?] Help

pressing [h] opens agent-shell-viewport-help-menu.

This would definitely be an improvement, but I think isn't quite optimal for my use case.

Let me add a bit more context:

At my site, we've implemented a command which uses agent-shell-viewport-edit-mode in a completely fire-and-forget sort of way. The implementation rebinds C-c C-c and C-c C-k to commands that do their normal function, but also delete the window displaying the viewport buffer. So, the workflow looks like:

1. Invoke fire-and-forget prompt command, which creates a new viewport buffer and calls pop-to-buffer to select it in a new window.
2. Type prompt in the viewport buffer
3. Press C-c C-c; we make this call agent-shell-queue-request so that the user does not have to know whether the agent is currently working or not, or wait for it to be done.
4. After C-c C-c or C-c C-k, restore the window configuration from before step 1.

So, in some sense, this command hijacks the viewport implementation in order to have:

• Header line information
• Easy access to the correct "place" to send the request
• agent-shell--context

But in this case, we're optimizing for the workflow where users don't really care to read the actual output from the agent, and instead just prompt it to make changes to files on disk and read the diffs there.

3. Split between header and mode line

See if we can potentially split information and render some of it in the header and remaining in mode line.

Alternatively, one could imagine putting some minimal help info in a comment (which would need to be stripped out before sending to the agent), or in an overlay with a before-string property.

It's hard to tell which one of these would work out best in practice unless we try them out. I understand this may be more than you had originally signed up for in the PR, so I'm happy to play with the alternatives if you prefer to defer the work.

ps. Kinda glad you ran into this bug ;) It tells me there are folks out there using the viewport interaction. I have a feeling there are only a few of us.

[xenodium]

Finally had a chance to look more into this...

The queuing flow you're describing is effectively a feature we're missing in the viewport flow (setq agent-shell-prefer-viewport-interaction t). Now added in 76459c2

I've also tweaked the header a bit in 8757b5c

? shows:

C-c C-h shows:

Give the viewport flow a try. IMO you'll get the flow that you're after but also benefit from the single-key bindings that enable quicker interaction as well as navigation.

Try with (setq agent-shell-prefer-viewport-interaction t)