Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idle. Search dialog found text not highlited on Windows #66375

Closed
BreamoreBoy mannequin opened this issue Aug 10, 2014 · 6 comments
Closed

Idle. Search dialog found text not highlited on Windows #66375

BreamoreBoy mannequin opened this issue Aug 10, 2014 · 6 comments
Assignees
Labels
topic-IDLE type-bug An unexpected behavior, bug, or error

Comments

@BreamoreBoy
Copy link
Mannequin

BreamoreBoy mannequin commented Aug 10, 2014

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
Copy link
Mannequin Author

BreamoreBoy mannequin commented Aug 10, 2014

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.

@BreamoreBoy BreamoreBoy mannequin added topic-IDLE type-bug An unexpected behavior, bug, or error labels Aug 10, 2014
@terryjreedy
Copy link
Member

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 terryjreedy changed the title Focus stays on Search Dialog when text found in editor Idle. Search dialog found text not highlited on Windows Aug 16, 2014
@terryjreedy
Copy link
Member

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
Copy link
Member

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

@terryjreedy terryjreedy self-assigned this Dec 19, 2014
@roseman
Copy link
Mannequin

roseman mannequin commented Sep 8, 2015

See bpo-24972 for fix

@terryjreedy
Copy link
Member

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

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-IDLE type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

1 participant