Feature/history

[Testudinidae]

Summary

This PR adds “History” and “Histroy × Suggestions” capabilities , and provides several tuning options to control the ratio and display caps of history vs. suggestions in the list. It also adds single-entry deletion and one-click purge of all history for a specific shortcut.

What was done

Save search history

• Record user input when executing a search (controlled per-shortcut by RecordHistory).
• Added HistoryEntry / HistoryStorage / HistoryService to encapsulate data structures, serialization, and file I/O.

Show history and suggestions together

• Introduced ItemIntegrate to merge Primary / History / Suggestions, de-duplicate, and trim the list according to settings.

Delete history

• Support deleting a single history entry.
• Support purging all history for a specified shortcut.

Settings

• Added global settings: MaxDisplayCount (maximum number of items shown) and MaxHistoryDisplayCount (maximum number of history items shown).
• Added per-shortcut setting: RecordHistory (whether to record search history for that shortcut).

UI updates

• Added a “Record History” toggle to the add/edit shortcut form.

User impact (behavior changes)

• During search, users will see history and suggestions together. The number of history items displayed can be controlled via MaxHistoryDisplayCount.
• Users can turn off history recording in the shortcut settings (RecordHistory: false).
• Users can delete a single history entry from the UI or clear all history for that shortcut.

⚠️ Important items for review

IntSetting and TextSetting label behavior

Because Microsoft.CommandPalette.Extensions.Toolkit does not include IntSetting, I implemented one modeled after TextSetting. I discovered that TextSetting’s Label is not used at all (it does not render in the UI), and I don’t know why it was designed that way. For consistency, IntSetting preserves the same “feature.” If you notice that the label does not appear, this is a feature, not a bug.

History retention / auto-deletion

I did not add automatic history deletion. In testing, even with 1M records there was no user-facing performance impact. If retention limits or auto-pruning are still desired, I can add them in a follow-up PR.

Behavior when RecordHistory is turned off

Turning off RecordHistory does not delete existing history, and I believe it should remain this way. History is keyed by the shortcut’s Name. Even if we introduce an Id in the future, I don’t think we should rebind to Id; multiple shortcuts with the same name sharing history is expected behavior. Therefore, if one of several same-name shortcuts disables RecordHistory, auto-clearing the shared history would be unexpected. If users want to remove history, they can do so via the shortcut’s More commands.

Renaming shortcuts and potential “ghost” history

If a shortcut is renamed, it can produce ghost history entries that remain in History.json but are no longer surfaced in the UI and cannot be deleted from there. This does not affect functionality, but it’s a privacy concern. I propose addressing it in a future PR.

Naming and persistence files — please double-check

The functionality is complete, but this PR is submitted as Draft because it will persist the following settings/files. Once released, renaming would be very troublesome, so please carefully consider whether these names are appropriate:

• settings.json

  • WebSearchShortcut.MaxDisplayCount
  • WebSearchShortcut.MaxHistoryDisplayCount

• WebSearchShortcut.json

  • New per-shortcut field: RecordHistory (bool)

• New file

  • WebSearchShortcut_history.json (stores search history; fields: Query, Timestamp)

Please provide feedback on:

• Whether the key prefix WebSearchShortcut. and its casing are consistent with existing settings.
  Other projects use forms like websearch, timeDate.
• Whether the two cap names (MaxDisplayCount, MaxHistoryDisplayCount) are clear.
• Whether RecordHistory is clear.
• Whether the file name WebSearchShortcut_history.json is clear, or if it should be WebSearchShortcut_History.json.
• Whether WebSearchShortcut_history.json should use field names Query and Timestamp (as in this PR) vs. aligning with the websearch project’s SearchString + Timestamp.