Add access keys to more Find/Replace dialog items

[debiedowner]

I was working on adding access keys to more Find/Replace dialog items, paying attention not to use the same access keys on different tabs, in light of @sasumner's warning in #9876. I was going to make a very limited pull request due to this constraint (The only available and usable keys are &j and &k; remaining &q, &v and &z are also available but not usable). But upon experimenting, I observed no clash when same access keys are used in different tabs. Looking at old issues, this problem indeed seems to be a thing as recently as 2019. I don't know what changed, but it is no longer the case in my testing.

Actually, this is easy to test without making any changes: @donho's fix 8fd691a for this problem only changed FindReplaceDlg.rc, not english.xml; so if you temporarily set your locale to English, both Find All in All Opened Documents in the Find tab and Replace All in All Opened Documents in the Replace tab have the underlined access key &O, but they work fine. Pressing Alt+O while in the Find tab correctly finds all in all opened documents, and pressing Alt+O while in the Replace tab correctly replaces all in all opened documents. I thought maybe the problem only happens for FindReplaceDlg.rc, but after modifying that and building, it still works fine.

Does either of you or anyone else have any insight or warning to share about this? Something like oh, we fixed it or it sometimes works and it's sometimes buggy, we don't know what causes it so don't mess with it? If not, I will assume that this was just a bug due to some component in the old build process and no longer something we need to worry about, me and other language translators. Because I agree with Swedish translator's comment in the issue that donho's commit fixed (#2276):

Clashes between Alt shortcut letters from invisible tabs should not be an issue, i.e. Notepad++ should never, in any dialog with multiple tabs, have shortcuts on invisible tabs swallow Alt letter shortcuts that appear on the active tab. It's not realistic to require that all Alt shortcuts be unique across all tabs. Being unique on the active tab should suffice and work as expected.

So if may be permitted to assume that now it will work as expected, I will add new access keys to items accordingly in a pull request; and also revert the existing ones to use the more intuitive keys instead of the workarounds due to this earlier bug, e.g. in the case of the aforementioned inconsistency between english.xml and FindReplaceDlg.rc, I will use the access keys of english.xml, thereby reverting donho's commit fixing this bug.

[sasumner]

@debiedowner

I was working on adding access keys to more Find/Replace dialog items, paying attention not to use the same access keys on different tabs, in light of @sasumner's warning ...

I think when I issued that warning I was attempting to explain the history of why the underlined-access keys in the Find window family of tabs was so strange/screwed-up/unmaintained. I meant to come back later with more information, but apparently I didn't get to it. :-(

Yes, some improvements have been made. See #8696 #8760 for the background and feel free to ask any questions. In short, one should be able to assign the same underline-access key 5 different times on all 5 tabs with no conflict potential -- but I think there could possibly be some lingering weirdness with this. Anyway, see the links above.

and also revert the existing ones to use the more intuitive keys instead of the workarounds

I like this idea personally, but I'm not sure how well it will be received by those that have gotten used to the keys assigned: "You broke my workflow!". BTW, I'm all in favor of breaking workflows, as long as it makes for a better product. I say "Develop a NEW workflow".

[debiedowner]

Thank you, I misunderstood your warning in yesterday's pull request. I didn't see those links; that explains it.

Regarding breaking workflows, my thinking in that example was that FindReplaceDlg.rc says one thing, english.xml another, so we would have to break somebody's workflow anyway if we make them consistent. But I now noticed that even if the English locale is selected so that english.xml's access keys appear, upon restart the access keys from FindReplaceDlg.rc return, and the change was temporary. Apparently english.xml is just for translators, no user actually uses that. I thought if you selected it in the menu, it remained with seemingly no way to go back, and that was why it was important to keep the access keys the same. Never mind.