Autocomplete UI for slash commands

[dlqqq]

Description

This PR adds an autocomplete UI for slash commands in the chat box. When the user types /, a list of matching slash commands is shown in the UI.

The list of slash commands is retrieved from a new REST API endpoint ListSlashCommands on GET /api/ai/chats/slash_commands. This only shows the list of slash commands which are valid for the currently selected provider, which handles the case of when unsupported_slash_commands is set in a custom provider.

Demo of first proposal

This is the UI implemented in this PR.

Screen.Recording.2024-05-31.at.11.05.52.AM.mov

Demo of second proposal

This is the UI implemented here: dlqqq#2

Screen.Recording.2024-05-31.at.12.23.59.PM.mov

[dlqqq]

I've opened a secondary PR that implements an alternative autocomplete design: dlqqq#2

I've updated the description of this PR to include a demo video of the alternative UI.

[dlqqq]

Feedback from Piyush:

• Increase box shadow on popup
• Increase right margin on icons

[JasonWeill]

Thank you for opening this PR! This looks really neat. Some feedback after using the primary branch:

1. Would you consider adding some kind of hint in the chat box that / starts a command? Discord has had an icon that kind of looked like [/] that typed a / and started a command popup. They have since replaced it with (at least on my phone) a weird four-shapes button that launches a command as a form. When the help message isn't visible, it may not be apparent that commands exist in the chat UI.
2. The help message uses an em dash (—) between a command and its description, but the popup uses a hyphen (-). Let's use the same separator, especially when both are visible.
3. Not introduced in your change, but the help message mentions magic commands below the list of commands. Is this still necessary? Magic commands can't be used in the chat UI, so it seems unusual to mention them in the Jupyternaut help message.
4. When I've typed a part of a slash command, like /cl, and I press TAB, instead of auto-completing to /clear (the only match), the focus instead shifts to the "Send" button. I had expected tab completion to work in response to the popup.
5. On the flip side, when I've typed all of a slash command, like /help, and I press ↩, the slash command does not get run; instead, the autocomplete popup is dismissed, with no visible difference. I had expected the command to get run.
6. When I've typed a part of a Slash command, like /gen, then tab out of the text area (see point 4 above), then re-enter the text area, I don't have the ability to continue autocompleting to /generate.
7. When I press ↩️ to auto-complete a partially-typed command, I expected there to be a space after the command: /generate instead of /generate. This would let me type a parameter after a command that accepts one.

[dlqqq]

@JasonWeill Thanks for the feedback. Let me address your callouts in order:

• For 1) and 3), I agree. Perhaps we could delete the sentence about magic commands (as they're not relevant to chat users), and modify the helper text shown in the chat input to say "Ask Jupyternaut (type / for more options)". However, I think these 2 points should be tracked in a separate issue to avoid scope creep.

2. The help message uses an em dash (—)...

• Fixed in the latest revision. Will include a screenshot of new updates in a follow-up comment.

4. When I've typed a part of a slash command, like /cl, and I press TAB, instead of auto-completing to /clear (the only match), the focus instead shifts to the "Send" button. I had expected tab completion to work in response to the popup.

• Unfortunately, this is due to the MUI library itself. The up and down arrow keys should be used to navigate through the popup menu via keyboard, not Tab. There doesn't seem to be a prop that enables "tab navigation" behavior either. You can verify this from the MUI autocomplete page, which contains demos: https://mui.com/material-ui/react-autocomplete/
  • In the same issue containing 1) and 3), you should consider including another action item for "adding helper text that indicates arrow keys should be used instead of Tab to navigate the autocomplete popup via keyboard". This will be easier than supporting tab navigation.

5. On the flip side, when I've typed all of a slash command, like /help, and I press ↩, the slash command does not get run; instead, the autocomplete popup is dismissed, with no visible difference. I had expected the command to get run.

• I believe this is expected behavior. While the popup is open, the "Enter" key selects the current option, which just so happens to be the exact same as what the user types. IMO this is still a good UX, as it essentially confirms to the user that the slash command they typed is recognized as a valid one by Jupyter AI.

(will continue, just posting partial reply now to avoid losing progress)

[dlqqq]

6. When I've typed a part of a Slash command, like /gen, then tab out of the text area (see point 4 above), then re-enter the text area, I don't have the ability to continue autocompleting to /generate.

• I tried some quick fixes to enable this behavior, but determined that this requires more complex handling of the open state, which further requires more unit tests. Right now, our handling of the open state is very simple so it is fine to leave it untested for the time being: we only open when the user types a forward slash as the first character.

• However, addressing 5) and 6) opens up the logic to multiple edge cases that will require unit tests to validate:

  • Open popup on focus, but only if it matches the prefix of an option,
  • ...unless it is equal to exactly one option, in which case we shouldn't show the popup,
  • etc.

• Given this, I think it's best to track this in a separate issue as well.

7. When I press ↩️ to auto-complete a partially-typed command, I expected there to be a space after the command

• Good callout, thanks! Done in latest revision.

[dlqqq]

@3coins @JasonWeill I've addressed your comments and this PR is ready for another round of review. Here is a demo of the latest revision of this branch for your convenience:

Screen.Recording.2024-06-05.at.11.10.27.AM.mov

[JasonWeill]

Generally looking good! Just a few non-blocking suggestions.

[dlqqq]

@JasonWeill Thanks! I'm tracking the remainder of your feedback in #820. I will merge this PR for now.

[jtpio]

cc @brichet for awareness.

I guess this is a feature that should / could be ported to https://github.com/jupyterlab/jupyter-chat