The history for search and replace is rather short (eight elements in all), which is a bit unpractical when applying the same S&R patterns over many documents.
Is it possible to customize the number of stored entries in the search and replace history list? If not, it would be cool to have a setting to control these.
But my main proposal here is to have ST handle two separate histories for plain searches/replace and RegEx based searches/replace. Since these two type of searches and replaces operations are quite different (and incompatible), it would make sense if ST would store them separately and show the history according to the type search (both for search as well as replace histories).
This feature alone would double the history by offering two separate lists, and it would make it much easier to work with different kinds of S&R operations across documents.
Keep in mind that when you select all occurences of a word via AltF3, the selected text ends up in the search history, which soon makes previous searches unreachable from the history. The same happens when using CtrD to select next occurence of a selection.
RegExs can be quite lenghty to write, so loosing them constantly due to simple operations like those just mentioned is kind of frustrating — I’ve proposed already to have a checkbox to lock the search field, in order to prevent this from happening. But separating the history for RegEx searches and nomral searches is even better a solution (the above keys shouldn’t count as RegEx searches).
Ideally, operations on selections with those keys shouldn’t pollute search history at all (regardless of the search type), for the history list should only show searches typed by the user in the search field, explicitly. But this might not hold as true for others, I guess.