ankitects / ankitects/anki

Autocomplete for Browser Search

Open
#2,465 6 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
30.5k
Forks
3.2k
Avg merge
2d 8h
Merged PRs (30d)
72

Description

From: https://forums.ankiweb.net/t/autocomplete-for-search/28995/7


Here’s what I’m thinking.

**Feature scope**:

1. Only applies to browse search bar for desktop Anki.
2. Autocomplete Anki keywords: “card”, “is”, “suspended”, etc.
3. Autocomplete user items: decks, tags, cards, etc.

**UI**:

1. 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
2. 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.
3. . 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**:

1. If it doesn’t already exist, create Anki search keyword constants list: “card:”, “is:”, “suspended:”, etc.
2. Create list of valid operators: “>”, “<”, etc. e.g. like “lapses>3”
3. …to be continued, it’s late and idk if this forum saves drafts

To implement keyword autocomplete alongside user item autocomplete, we'll just run the search against two lists (keyword_list, user_items_list), and then merge the results, appending user_items_list behind keyword_list's result. Should add visual indicator in UI, maybe a thick horizontal line, to differentiate keywords/items in the dropdown.


Possible future overhead:
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

Contributor guide

Open the contributing guide

Research direction

Start from the desktop Browse search bar and review how its recent-search dropdown currently handles focus, clicks, and arrow keys. Define the autocomplete behavior for keywords and user items, including keyboard navigation, Tab completion, visual separation, and dismissal; done means these interactions work without obscuring recent searches.

Written by the indexing model from the issue text.

Assessment

Domain
desktop, search
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.