Getting opinions from dae and the community on whether we want autocomplete in the browser search bar for stuff like card names, deck names, and search keywords (is, deck, tag, etc).
@dae, I’d dev this myself. I understand that there’s already an add-on but I don’t think that adding this as a standard function would add maintenance overhead. I could be wrong though, let me know your thoughts?
I’d say every line of code adds maintenance overhead, but this feature would be really nice to have if it’ll be aware of the search syntax, for example suggesting decks only when the deck operator is used.
It will in fact add a non-trivial amount complexity to the codebase, but I agree it would be a handy feature.
If you’re able to contribute a clean implementation in Rust, I would be happy to include it. To simplify the frontend, maybe the API could be something like:
suggest_search_completions(search_text: str, cursor_index: int, max_completions: int = 500) → list[str], which is vaguely similar to the existing complete_tag() we have. The returned items would be just the completed part
apply_search_completion(search_text: str, cursor_index: int, selected_completion: str) → str, which takes care of stripping off the typed part and replacing it with the selected completion.
One thing that will need thinking about is how you present the completions - currently the search bar already has a dropdown for saved searches.
Do you mind if I open a GitHub issue for this so it’s easier to track discussion and iteration?
Here’s what I’m thinking.
Feature scope:
Only applies to browse search bar for desktop Anki.
Autocomplete Anki keywords: “card”, “is”, “suspended”, etc.
Autocomplete user items: decks, tags, cards, etc.
UI
Autocomplete (AC) creates a dropdown when it detects a completable term.
a. Dropdown is clickable and navigable with arrow keys
b. Autocompletes with Tab key
c. Dropdown disappears when focus is lost or when the search bar is empty
Autocomplete (AC) takes over the down and up arrow functionality from the recent search dropdown. However, the AC dropdown defers to search dropdown, i.e. when the user clicks on the recent search expansion button on the right side of the search bar, AC dropdown disappears, replaced by recent searches.
AC dropdown doesn’t use full width of dropdown. I want it to look more like an IDE autocomplete, taking only the width needed for completion.
a. Regardless of what it ends up looking like, it needs to be visually dissimilar enough from recent searches that users understand that recent searches still exist and that this is only term autocomplete, not search autocomplete.
API
If it doesn’t already exist, create Anki search keyword constants list: “card”, “is”, “suspended”, etc.
Create list of valid operators: “>”, “<”, etc. e.g. like “lapses>3”
…to be continued, it’s late and idk if this forum saves drafts
What overhead can you think of?
Here’s what I have:
API changes: If search keywords change, we should only have to update the central constants+operators file, minimal work
User Interface (UI) updates: can’t think of any besides the obvious: if search changes, dropdown presentation may have to change
Uh, I just posted a pretty long comment detailing my design approach but I’m not sure if it just got lost while editing it lol, luckily, I had a draft saved, but it’s shorter. Commenting this anyways so I can sleep
Do you mind if I create an issue in github so we can better track discussion and iteration?
Draft:
Feature scope:
Only applies to browse search bar for desktop Anki.
Autocomplete Anki keywords: “card”, “is”, “suspended”, etc.
Autocomplete user items: decks, tags, cards, etc.
UI
Autocomplete (AC) creates a dropdown when it detects a completable keyword.
a. Dropdown is clickable and navigable with arrow keys
b. Autocompletes with Tab key
c. Dropdown disappears when focus is lost or when the search bar is empty
AC will defer to current recent search dropdown
API
If it doesn’t already exist, create Anki search keyword constants list: “card”, “is”, “suspended”, etc
Your comment got caught by the spam filter and needed manual approval. Feel free to move this discussion over to GitHub if you’d like.
The initial Rust backend+Qt frontend implementation will just be for the desktop, but my thinking with the API proposed above is that it will make it fairly easy to integrate with the mobile frontends later.
I presume you mean card: and is:. Do we want that? The suggestions might get in the way of people trying to type unqualified searches. I’d assumed you’d just be focusing on the arguments on the right side of the colon, like is:[suspended, due, etc], and decks, tags, template names, etc. If you try to complete on the left as well and plan to support fields, that means we’d have to search the entire list of field names for every character typed, which may also have a performance impact.
Aside from what you’ve mentioned, the main one is that the cost of maintaining a codebase tends to be proportional to the number of lines of code it contains. More features means more things that can go wrong, and potentially more work when things need to be refactored/reworked.