Feature: standalone register_slash_command() for chat_ui() without chat_server()

[kaipingyang]

Summary

chat_app.R has a standing TODO to "Support a standalone register_slash_command() that works outside the returned environment (e.g., so callers don't have to thread the return value)." This proposes exactly that.

Motivation

Slash commands are currently only reachable through chat_server()'s $slash_command() method. That has two friction points:

1. You must thread the returned object around. To register a command from anywhere other than right next to the chat_server() call, you have to capture and pass its return value.
2. Fully custom chat loops can't use slash commands at all. The Get started vignette says as much: "Slash commands are currently available only through chat_server(), not when building a fully custom chat loop with chat_ui() and chat_append() directly." Apps that drive chat_ui() with their own server logic (custom streaming, an external agent loop) can't offer the official palette.

Proposal

Export a free function that mirrors $slash_command() but is callable anywhere with just the chat id and session:

register_slash_command(
  id, name, description, handler, ...,
  echo = NULL, force = FALSE,
  session = getDefaultReactiveDomain()
)

• Same handler semantics as $slash_command() (0/1-arg, or NULL for client-side handling via shiny:chat-slash-command); a 1-arg handler receives a ContentSlashCommand.
• The command registry lives in session$userData keyed by the namespaced id (the same idiom already used for bookmark info in chat_restore.R), and the dispatch + sync observers are set up once, lazily — so no return value needs threading.
• The slash machinery is factored into an internal helper that chat_server() reuses, so both paths share a single implementation and can't drift.

Follows shinychat's argument conventions (id first, session last, matching chat_append() / chat_clear() / update_chat_user_input()).

Open question

R's $slash_command() returns an unregister closure; I've kept that for register_slash_command(). Would you prefer a separate remove_slash_command(id, name, session) for parity with the Python Chat.remove_slash_command() method, or is returning the unregister function the right R idiom here? Happy to adjust.

I have a draft PR ready that implements this as a pure refactor (no behavior change to chat_server()), with standalone tests and a clean R CMD check.

[cpsievert]

Hi @kaipingyang, out of curiosity, can you elaborate a bit on why you want to avoid using chat_server()?

[kaipingyang]

Hi @cpsievert — our pipeline runs compaction, permission gating, and local-command handling before every request goes out, and chat_server()'s input observer always fires its own stream_async() on submit with no hook to intercept that — running both together double-streams. Slash typeahead is the one piece we'd still like without adopting the rest, hence this PR.

[gadenbuie]

Request start/end hooks are coming to ellmer soon in tidyverse/ellmer#1052. Do you think those callbacks would address your use cases?

If it's not possible to have a slash command skip the chat input in R with chat_server(), that's either a bug or a gap we can close.

Between the above two points I think your needs would be covered, but if not I'm certainly open to chat_server() gaining a hook for input transformation.

[kaipingyang]

Thanks @gadenbuie — really appreciate the pointer to tidyverse/ellmer#1052 and the slash-command clarification.

Verified tidyverse/ellmer#1052 covers our case. The async loop invokes on_request_start with await() + invoke_async(), and the doc explicitly allows a promise return:

       while (!is.null(user_turn)) {
+        await(private$callback_on_request_start$invoke_async(c(
+          private$.turns,
+          list(user_turn)
+        )))
         assistant_chunks <- private$submit_turns_async(

#'   With `$chat_async()` / `$stream_async()` the callback may return a promise.
on_request_start = function(callback) {
  private$callback_on_request_start$add(callback)
},

So our compaction step (itself an LLM call) can run there without blocking — that closes the "rewrite before send" gap.

You're also right on slash commands: on_chat_slash_command is a separate observer from on_chat_user_input, so a handler that skips client$stream() never reaches the LLM. We'd conflated "any input" with "slash-triggered input" — that half was already solved, we just hadn't mapped our local commands onto it.

The input-transformation hook idea sounds great — I'd love to hear more about it whenever you have time, and happy to help however's useful.