Skip to content

Remove T9 search text-entry option; default to multitap keypad entry#458

Open
brickbots wants to merge 1 commit into
mainfrom
remove-t9-text-entry
Open

Remove T9 search text-entry option; default to multitap keypad entry#458
brickbots wants to merge 1 commit into
mainfrom
remove-t9-text-entry

Conversation

@brickbots

Copy link
Copy Markdown
Owner

Summary

Name Search previously offered an optional T9 search mode (the t9_search setting): press each number key once and object names are matched against their keypad-digit sequence. The default — and now the only — behavior is multitap keypad entry: press a key repeatedly to cycle through its letters (7a/b/c…), building a text string that is matched with a plain case-insensitive substring search.

This PR removes the T9 option entirely and makes multitap the sole text-entry mode.

Changes

  • Config: drop the t9_search key from default_config.json.
  • Menu: remove the Settings → User Pref → T9 Search item from menu_structure.py.
  • UI (textentry.py): remove the t9_search_enabled property and its branches; _perform_search always calls search_by_text, and key_number always uses multitap.
  • Catalog (catalogs.py): remove the now-unused search_by_t9 machinery — keypad digit maps (KEYPAD_DIGIT_TO_CHARS, LETTER_TO_DIGIT_MAP), the _t9_cache and its helpers, the cache-invalidation calls, and the now-unused import re. search_by_text is unchanged.
  • Tests: delete test_t9_search.py; update test_web_remote_settings.py for the User Pref index shift (Language moves from index 6 → 5, so navigation uses one fewer D).
  • Docs: drop T9 references from user_guide.rst and the docs/ax/{catalog,catalog/CONTEXT,ui} references; light wording fixes in the docs skill knowledge base.

Notes

  • RELEASE.md (shipped v2.5.1 changelog, already tagged) is intentionally left unchanged — it's a historical record.
  • The translation catalogs (locale/*/messages.po) still contain an orphaned T9 Search entry. It's harmless (no longer referenced) and will be removed at the next nox -s babel sync. A full babel run here would have churned ~2,600 lines of unrelated source-line references (the catalogs are refreshed periodically, not per-PR), so it was deliberately left out.

Testing

  • pytest -m "smoke or unit"281 passed.
  • Catalog/text-entry tests → 18 passed, 9 skipped.
  • ruff check clean on changed files; mypy reports no errors in the changed modules.
  • Web settings test file collects cleanly (Selenium-gated tests skip locally).

🤖 Generated with Claude Code

Name Search offered an optional `t9_search` mode (press each key once;
match object names against keypad-digit sequences) alongside the default
multitap entry (press a key repeatedly to cycle through its letters).
This removes the option entirely, so name search always uses multitap
entry plus substring text search.

- Remove the `t9_search` config key and the "T9 Search" Settings menu item
- Drop the t9_search_enabled branch in UITextEntry; always use search_by_text
- Remove the now-unused Catalogs.search_by_t9 machinery (keypad digit
  maps, _t9_cache, helpers) and its dedicated test
- Fix the User Pref submenu index shift in the web settings test
  (Language moves from index 6 to 5)
- Update the user guide and ax/catalog/ui docs to drop T9 references

Translation catalogs still contain an orphaned "T9 Search" entry; it will
be removed by the next `nox -s babel` sync (run periodically, not per-PR).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@mrosseel

mrosseel commented Jun 9, 2026

Copy link
Copy Markdown
Collaborator

hi @brickbots , why did you remove the new entry method, was something broken with it?

@brickbots

Copy link
Copy Markdown
Owner Author

Hi @mrosseel thanks for spotting this PR!

I don’t think I’m going to merge this, but I wanted to invite a conversation. This is actually a fairly common support question. Either people asking what it is, or enabling it thinking that it is the existing multi-tap method which they couldn’t find otherwise.

I like this feature, but I feel like it really needs to be paired with a dynamic list of objects… more like the old smart phone system.

As it is you just type numbers with little feedback and I’m not sure many people actually get it. So I’d like to figure out how to make this more understandable and useful. This might just be better documentation, but I’d like it to be more digestible without resorting to the user manual if possible.

Thoughts (from anyone)? Is this something people are successfully using and preferring? I only get the negative side of things from the support emails, so I don’t want to over index and hide it or remove it.

@dnlombard

Copy link
Copy Markdown

I like this feature, but I feel like it really needs to be paired with a dynamic list of objects… more like the old smart phone system.

As it is you just type numbers with little feedback and I’m not sure many people actually get it. So I’d like to figure out how to make this more understandable and useful. This might just be better documentation, but I’d like it to be more digestible without resorting to the user manual if possible.

A dynamic list responding to each keypress is a critical part of T9 and provides the feedback needed to use the feature effectively. There was also a learning component to prioritize past choices; I'm not if that's a should or nice-to-have.

if there was a T9 option but without an adjacent multitap option, that might explain the support questions.

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