Skip to content

Fix: allow tab auto-complete without executing#2325

Open
joshbarrington wants to merge 2 commits intodocker:mainfrom
joshbarrington:fix/tab-auto-complete
Open

Fix: allow tab auto-complete without executing#2325
joshbarrington wants to merge 2 commits intodocker:mainfrom
joshbarrington:fix/tab-auto-complete

Conversation

@joshbarrington
Copy link
Copy Markdown

This fixes issues:
#2257
#1819

There was another implementation for a fix here: #2275

However I expanded upon that by simplifying and removing AutoComplete from the command interface, as this was hardcoded to be always true. It is now driven by the Update function directly.

I also added some more exhaustive tests and changes suggested through mise lint.

@joshbarrington joshbarrington requested a review from a team as a code owner April 4, 2026 17:56
@yunus25jmi1
Copy link
Copy Markdown
Contributor

Thanks for referencing #2275 and building on it! I can see this version simplifies the implementation by moving the execute behavior into Update() directly and expands the tests as well. This looks like a cleaner approach to fix issues #2257 and #1819. I'm happy to defer to this implementation if maintainers prefer this direction. Looking forward to the review!

@krissetto
Copy link
Copy Markdown
Contributor

Hey! Thanks for the contributions @joshbarrington && @yunus25jmi1

Both here and in #2275 we need to pay attention to not create regressions. As-is, this breaks the UX in other parts of the app.

Auto-complete in it's current shape is not only used for /commands, but also for things like @attachments.

With these changes:

  • if a user types @ and then hits tab on Browse files.. the file picker will no longer open, the @ will disappear and a single space will be left instead. That's confusing;
  • if they press enter on a file the message with the attachment gets sent immediately. That's also undesired, as the goal is to autocomplete the filename and attach it instead, not attach and send in a single action because the user might want to continue their message before sending it.

We need to think about supporting both scenarios, so /commands are a bit less annoying, and @attachments continue to work as they were designed to

Not sure who wants to take on the changes, but we're glad to get changes merged as soon as they don't unintentially break other types of auto-complete :)


Screencast below shows the problematic behavior:

Screen.Recording.2026-04-04.at.21.37.24.mov

Copy link
Copy Markdown
Contributor

@krissetto krissetto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

☝️

@joshbarrington
Copy link
Copy Markdown
Author

@krissetto Thanks for the heads up on the regression. Are there any other inputs such as the '@' symbol that we need to be aware of?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants