FarManager: Find file search text not saved when cleared

Thank you for the early feedback, @rohitab, always appreciated.

OK. Let’s get back to basics. The original complaint here was that the empty search pattern is not saved across FF invocations. I am going to implement the following:

• Add Find-File-specific persistent search options which include flags (CS, WW, Fuzzy).
• On close, copy all options, both search pattern and flags, to the E/V persistent instance if the search pattern is not empty.

Sold!

persisting across Far sessions?

Probably no. That was not the case before the latest changes and I don’t remember anyone ever requesting that.

An empty search string does not make any sense in Viewer & Editor. We probably should just forbid that by disabling Prev/Next/All buttons in the dialog (see Windows Notepad for example).

In Find File, however, it does. Moreover, conceptually empty/non-empty is not about the string value per se, but about using or not using the content search, i.e. it is sort of a weird checkbox. If the user cleared the text to not look in files’ data, we definitely do not want to restore it on the next invocation.

To summarize:

1. Viewer, Editor and Help search dialogs should not allow persisting empty search strings at all.
2. Find File should, but this “emptiness” should stay within Find File and should not propagate into the global state. Pseudocode:

bool Config.FindFile.ContentSeach;

...

FindFileDialog.OnCreate():
    FindFileDialog.ContainingText = Config.FindFile.ContentSeach? GlobalSearchString : "";
    
FindFileDialog.OnClose():
    Config.FindFile.ContentSeach = !FindFileDialog.ContainingText.empty();
    if (ContentSeach)
        GlobalSearchString = FindFileDialog.ContainingText;

1. All other content-related options (CS, WW, Regex…) in Find File could either be persisted unconditionally (if the user “accidentally flipped some checkboxes”, they can always flip them back) or only when the string was not empty. I don’t have a strong preference here.

Sure thing. I figured as much. Just looking at the replaced code, it’s hard to tell that it would introduce this issue. I wouldn’t have found it either during a code review.

Just speaking for myself here. I’m fine with clearing the search string, i.e., not imitating the old behavior where the search string in the Editor/Viewer is not cleared. Since everything else is shared between the searches, it makes sense to share the search string as well. Of course, other users might disagree and expect the old behavior.