[mfkeeq199458]

The Last used dropdown now ends with a separator and a localized Clear recently used row that empties the file history list, persists the settings immediately, and rebuilds the menu. The row is disabled when the history is empty. Clearing only touches FileHistoryList; the search, filter, URI, regex and columnizer history lists are untouched.

The click handler tells the new row apart from the file entries by reference, so the displayed text is never treated as a path.

RemoveFromFileHistory and its HistoryItemRemoveRequested wiring are removed along with it: the right-click-to-remove handler subscribed to the dropdown's MouseUp, which a ToolStripDropDownMenu only raises for clicks outside its items, so the remove path never fired and is dead code.

Tests: ClearFileHistoryTests covers clearing, persistence and that other history lists survive; MenuToolbarControllerTests covers the menu layout, the disabled state and that clicking the clear row does not raise HistoryItemClicked.

[Hirogen]

Thanks for this, @mfkeeq199458 — clean, well-scoped change, and the tests are nice.

I double-checked the dead-code claim against the WinForms source: ToolStrip.OnMouseUp only raises the public MouseUp when no item is under the cursor, so OnHistoryStripMouseUp could never have removed an entry (a right-click on an entry actually just opened the file via ItemClicked). Agreed, removing it is correct.

A few small, optional things:

• Naming: the field is _clearHistoryItem, the control is clearFileHistoryToolStripMenuItem, and the event is HistoryClearRequested. Could we settle on one, e.g. _clearFileHistoryItem / FileHistoryClearRequested?
• Comment on _clearHistoryItem (MenuToolbarController.cs:52) can go; the name already says it.
• Locking: ClearFileHistory mutates the list without _loadSaveLock, while ClearLastOpenFilesList right below takes it. AddToFileHistory doesn't lock either, so it's consistent, but taking the lock would match the neighbouring clear method.
• Double rebuild: LogTabWindow calls FillHistoryMenu explicitly, and the Save → ConfigChanged → ApplySettings path rebuilds it again. Harmless; feel free to drop the explicit call or leave it.
• Tests: ResetConfigManagerInitialization duplicates the helper in ConfigManagerPortableModeTests. Not blocking, just noting it as a candidate for a shared helper later.
• The whitespace-only change in IConfigManager.cs:178 can be reverted to keep the diff minimal.

None of these block merging. Happy to merge as is later this day, or after a quick touch-up if you want to address the naming.

[Hirogen]

Thanks @mfkeeq199458, that addresses everything.

• Naming is consistent now (_clearFileHistoryItem / FileHistoryClearRequested / clearFileHistoryToolStripMenuItem)
• The lock in ClearFileHistory matches ClearLastOpenFilesList
• I traced the rebuild path: Save → ConfigChanged → ApplySettings → FillHistoryMenu runs synchronously, so dropping the explicit call is fine, and the comment explaining it is helpful
• Nice to see the shared ConfigManagerTestReflection helper, plus the fail-fast change for the portable-mode tests

One tiny nit: using LogExpert.Core.Config; in ConfigManagerTestReflection.cs is unused. Not blocking, so feel free to fix it or leave it.

Approving, thanks for the contribution!