In Windows, the 'find' and 'replace' dialogs do not work properly on text that has been commented out using quotation marks.

More specifically, the dialog *finds* the text in question, however, it does not *highlight* it. Without the highlighting, a user can't see which text has been found. Since the whole point of the find function is to show the user where the text is located, this is a bug. 

Credit for the fix goes to Roger Serwy, who suggested raising the hit tag.

My patch uses the show_hit function from patch 17511*. I have included the show_hit function, but not the rest of patch 17511.

Are there guidelines for submitting patches that utilize elements of other patches?

*show_hit is originally from the ReplaceDialog. 17511 added it to SearchDialog

Yes, we make the issue have a dependency on the issue it is using.  I have done that for this one.

I closed #18590 as a duplicate of this.

The patch for #17511 did not solve the issue; I proposed a revision in #22179.  A patch for that may fix this also.

I should note that in msg225543 of #22179, I verified that there is a problem in Replace for highlighting found text within quotes, as well as in keywords, until the dialog is closed.  On the other hand, the same text is hihglighted in identifiers, plain code, buildin names, and comments.  This might be an issue of stacking order. Merely using replace.show_hit in search also will not solve this.

I am narrowing the scope of this issue to Replace dialogs and widening the scope to output as well as edit windows. The attached patch solves the issue as redefined.  (It has a temporary hack to pass the unittests.)

For edit windows, the problem is that the default tag stacking order seems to be alphabetical.  No tag, 'builtin, 'comment', and 'definition, are followed and dominated by 'hit'; 'keyword' and 'string' come after and dominate 'hit'.  The solution is to raise 'hit' to the top.  The test (from msg225543), which should be added to htest), is that all 6 'i's in "def i(): this list is 'is' # is not" are both found and highlighted.  They are with the patch.

For output windows, the problem, mentioned in msg225382, is that the 'hit' tag is configured in ColorDelegator, which is not used in output windows.  Ths solution, also mentioned there, is to move the configuration to SearchDialogBase.  The path does this and Replace dialog Find work for Output Windows.

I tested on Windows.  I am 99.9% sure there should be no problem on other systems, but would like confirmation on other systems before or after committing an expanded patch with test changes added.

Additional notes: Sarah's Replace patch consists of the tag raise.  I just verified the reason why it works and moved it to the dialog base to include output windows and soon, Search dialogs.  Sarah, if you do not provide a 'family' name, I will list you in Misc/ACKS, in alphabetical position, as just 'Sarah'.  Or are you already in that file?

Currently, Replace dialog Find hits are tagged with both the 'hit' and the 'sel' tag, which does not show on Windows as long as the dialog is the active window, but apparently does on other systems.  Raising the hit tag to the top (either patch) means that the visible highlight on other systems will change from 'selected' to 'found' (which are independently configurable in Idle preferences).

If this not desired, the patch could be altered to use tag 'hit' on Windows and 'sel' elsewhere; change 'hit' (on Windows) to 'sel' when the dialog is closed; and configure 'hit' to look like 'sel' (so there is no visible change when closing, as on other systems).

On Windows, only one slice can be selected and I presume this is true on other systems.  If so, a non-'sel' tag is needed on all systems to tag multiple hits.  I would like to auto-highlight all hits in grep output windows and add an explicit 'find in current file' option (though it is possible now by adding the file name to the search path).

Raymond, I added you as nosy since this is an appearance change issue that you might possibly have an opinion on, and I would prefer getting it before a change is released in January  If I am wrong, un-nosy yourself.

I tested for the behaviour described in msg193895 before and after your patch. Everything remains same except as what you mentioned.

>Currently, Replace dialog Find hits are tagged with both the 'hit' and the 'sel' tag, which does not show on Windows as long as the dialog is the active window, but apparently does on other systems.  Raising the hit tag to the top (either patch) means that the visible highlight on other systems will change from 'selected' to 'found' (which are independently configurable in Idle preferences).
>
>If this not desired, the patch could be altered to use tag 'hit' on Windows and 'sel' elsewhere; change 'hit' (on Windows) to 'sel' when the dialog is closed; and configure 'hit' to look like 'sel' (so there is no visible change when closing, as on other systems).

It would be better to ensure that there is no visible change when closing.

See #24972 for fix

#24972 fixes the immediate issue but the Find and Replace code are needlessly different in doing the same thing and redundant in double tagging found text, and there are some other glitches.  I think a better fix will be to only use the found tag, but this needs discussion, perhaps on idle-dev. #22179 also has some discussion.

Since the original bug for this issue has been fixed, I am closing it in favor of #29392