Idle. Search dialog found text not highlited on Windows

[BreamoreBoy]

BPO	22179
Nosy	@terryjreedy, @serwy, @roseman

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/terryjreedy'
closed_at = <Date 2015-10-12.02:31:30.584>
created_at = <Date 2014-08-10.12:01:02.591>
labels = ['expert-IDLE', 'type-bug']
title = 'Idle. Search dialog found text not highlited on Windows'
updated_at = <Date 2015-10-12.02:31:30.582>
user = 'https://bugs.python.org/BreamoreBoy'

bugs.python.org fields:

activity = <Date 2015-10-12.02:31:30.582>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = True
closed_date = <Date 2015-10-12.02:31:30.584>
closer = 'terry.reedy'
components = ['IDLE']
creation = <Date 2014-08-10.12:01:02.591>
creator = 'BreamoreBoy'
dependencies = []
files = []
hgrepos = []
issue_num = 22179
keywords = []
message_count = 6.0
messages = ['225138', '225382', '225543', '232917', '250237', '252839']
nosy_count = 4.0
nosy_names = ['terry.reedy', 'roger.serwy', 'markroseman', 'BreamoreBoy']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue22179'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

[BreamoreBoy]

As the title. Even using the Find Next button doesn't get the focus on the found text so you can't see it, the Search Dialog has to be closed. Windows 8.1 Python 3.4.1.

[terryjreedy]

The focus *should* stay on the dialog, bpo-17511, but the found text should be highlighted with the 'found' highlight, as it is for Replace in Editor (but not Output) windows. The issue is that found text on Windows is not hightlighted in any way. It apparently is on other platforms, though I am not sure which way (but probably as 'selected' rather than 'found'). Hence the title change.

There must be some difference between the Find Next code in Search dialog and the Find code in Replace. The relevant code for Find Next is SearchDialog.SearchDialog.find_again, after 'if res:' (if pattern found). The corresponding code in Find is ReplaceDialog.ReplaceDialog.do_find after the 'if not res:' block.

I believe I found the crucial difference. Do_find is similar to find_again except for putting the tag and show code in a separate .show_hit method. Show_hit has code to clear and then set a 'hit' tag. The hit tag is associated with the hit (found) highlight in ColorDelegator.LoadTagDefs and config_colors.
# The following is used by ReplaceDialog:
"hit": idleConf.GetHighlight(theme, "hit"),
and self.tag_configure(tag, **cnf)

The fix is to use 'hit' in SearchDialog also. I believe the show_hit slightly modified could be moved to SearchDialogBase and used in find_again.

For output windows, Search is active but ColorDelegator is not. ColorDelegator does not use 'hit'. The tag_configure for 'hit' can and should be moved to SearchDialogBase. (I either have or will moved 'break' confiuration away.)

A note on selection highlighting. When Debugger is running with [x]Source, source lines are marked with the 'selected; highlight. Debugger.Debugger.show_source calls Debugger.sync_source_line which calls self.flist.gotofileline(filename, lineno) which selects the line in the file.

In msg186609 of bpo-17511, which was about keeping the dialog open after Find Next, Roger claimed that the patch for bpo-14146, which was about highlighting source (as selected) when debugger is open, would also fix highlighting found source when Find is open. The patch, b56ae3f878cb (for 3.4) adds a Windows-specific "def _highlight_workaround(self)" to EditorWindow. But is does not cause select highlighting in either Search or Replace windows. I believe it works for Debugger because gotofileline temporarily changes focus to the editor window containing the file, raising it to the top, before focus shifts back to Debugger, putting it back on top of the editor (usually) if there is overlap. The highlight workaround highlights the sel_fix tag (a substitute for sel) as focus leaves the editor.

To mark found text with the 'selected' highlight, we would have to shift focus temporarily to the editor by some other means. But 1. the 'experimental' debugger is temperamental and sometimes freezes Idle, and I don't know if the focus shifting has anything to do with that; 2. I think consistently using the 'found' highlight for both search dialog is better anyway.

[terryjreedy]

As it is now, show_hit should have a comment something like this:

# On Windows, selection highight is visible while the dialog is open.
# A 'hit' tag is used while the dialog is open (see bpo-22179).
# The 'hit' tag should be deleted when this dialog is closed.
# The 'sel' tag keeps the text marked after closing.

However, there is a slight bug in show_hit behavior. For example, finding 'i' in "def i(): this list is 'is' # is not" finds all 6 'i's, one after the other, but only the 4 in identifier, plain text, builtin, and comment are visibly highlighted. The 2 in the keyword and string are not. The selection tag, however, is visible on the 'i' of "is" or "'is'"after the dialog is closed. Checking ColorDelegator, I do not see an obvious reason for why two tags are handled differently.

If this cannot be fixed, we should try the alternate fix of making the sel tag visible and dump the found tag. Otherwise, I think I like the heavier highlighting while the dialog is open.

[terryjreedy]

The first # comment above should be "On Windows, the selection highlight is *not* visible while the modal dialog is open." This bug was, in a sense, introduced by bpo-17511, which kept the dialog open after [Find] is pressed, instead of closing it immediately.

About the last comment: the selection tag does not need to be applied until closing. (Ditto for find/replace.)

The missing found highlighting for Replace is issue bpo-18590

[roseman]

See bpo-24972 for fix

[terryjreedy]

I am closing this because bpo-24972 fixes the immediate issue.