The current way to define a trigger is in the extension manifest as a preference with type "keyword".

There is no way to define a trigger without a keyword, and in its place there's only a hacky workaround (discovered by me before I was the maintainer). This workaround no longer works in v6. And rather than trying to "fix the workaround" it would be better to officially support this type of behavior. Essentially there are three scenarios:

1. ✅ Keyword and argument (supported now for extensions and shortcuts)
2. ❌ Application-like triggers without arguments
3. ❌ Arguments without shortcuts (like the calculator)

This proposal is an API change to support 2 and eventually 3, by moving the shortcuts from preferences to a new place "triggers" (preferences will remain as an optional list for actual preferences).

{
  "required_api_version": "3",
  "name": "My extension",
  "description": "Description",
  "developer_name": "John Doe",
  "icon": "images/icon.png",
- "preferences": [
+ "triggers": [
    {
      "id": "demo_kw",
-     "type": "keyword",
      "name": "Demo",
      "description": "Demo extension",
-     "default_value": "dm"
+     "keyword": "dm",
+     "icon": "images/optional-alternative-icon.png"
    }
  ]
}

#1056 already laid the ground work to keywords no longer being considered as "preferences", and #817 fits in better with this as well (confusing to have optional icon arguments for "preferences" that only applies to keywords).

Note:

• The keyword argument is optional. If unspecified, the trigger would work as an application-like trigger instead.
• Note to self: The old get_searchable_items() in the modes should be renamed to get_triggers()

To support case 3 we would have to add another argument (validation pattern/regex). and also make a user interface in the preferences to let users opt in for this for the extensions they want to work without the keyword (because it shouldn't be up to the extension devs). This will require more work.

Related to #306, and #1072