[mfkeeq199458]

Adds a clear entry at the bottom of File -> Last used that empties Settings.FileHistoryList and persists it immediately. Only the recent files list is affected; search, filter, filter-range, URI and regex histories are left untouched.

• ConfigManager.ClearFileHistory() clears the list and calls Save(SettingsFlags.FileHistory)
• MenuToolbarController builds the item at runtime, raises HistoryClearRequested on click and excludes the item from the right-click removal path so it is never treated as a file name
• The item stays visible but disabled when the history is empty
• Resources for en, zh-CN and de plus the matching Designer property
• Tests: ConfigManager.ClearFileHistory (3) and menu behaviour (2)

[Hirogen]

Review

The behaviour works end to end. Most of the points below are about test coverage and how the description is worded.

Verified

• LogTabWindow subscribes to HistoryClearRequested, then calls ClearFileHistory() and FillHistoryMenu().
• The item is added last, after a separator. The separator only appears when the history isn't empty.
• The item is disabled when the history is empty (Enabled = history.Count > 0).
• Both the left-click and right-click paths skip the item, so it is never treated as a file name.
• The resource key is the same in en, de, zh-CN and Resources.Designer.cs.
• Only FileHistoryList is cleared. The other histories are not touched.

Suggestions

Tests

• No test covers the right-click path, even though the description says the item is excluded there. A test that right-clicks the clear item and checks that no removal is raised would cover it.
• ClearFileHistory_LeavesOtherHistoryListsUntouched checks Search, Filter and Columnizer. The description lists search, filter, filter-range, URI and regex. FilterRangeHistoryList, UriHistoryList and RegexHistory aren't checked, and Columnizer isn't on the list.
• The reflection that resets the singleton in ClearFileHistoryTests repeats ConfigManagerPortableModeTests.cs (lines 72-76). A small shared test helper would cover both.

MenuToolbarController

• The clear item is found by its Name string in two places: the click handler and the mouse-up handler. File entries are still found by their Text. Keeping a field reference to the clear item, or putting the file path in Tag on the file entries, would remove the special case.
• var history = fileHistory as IList<string> ?? [.. fileHistory]; keeps a reference to the live Settings.FileHistoryList. When PopulateFileHistory is queued from another thread, the list could change before it runs. The current caller is on the UI thread, so this doesn't happen today, but writing [.. fileHistory] would always make a copy.

ConfigManager

• ClearFileHistory doesn't take _loadSaveLock. That matches AddToFileHistory and RemoveFromFileHistory, but ClearLastOpenFilesList right below it does lock. Locking here would avoid racing a Save that is running at the same time.

Description

• "Only the recent files list is affected" is true for what gets cleared. But Save(SettingsFlags.FileHistory) writes the whole settings.json; the flag only goes to OnConfigChanged. Add and Remove already work this way, so it isn't a regression. It just shouldn't be read as "only that list is saved".

Minor / no action needed

• The new event subscription in LogTabWindow is never unsubscribed. The other handlers there don't unsubscribe either.
• Calling ToolStrip.OnItemClicked through reflection in the menu tests is brittle but practical.
• The SetUp and TearDown comments in ClearFileHistoryTests could be shorter.

[Hirogen]

as commented :)