When I use the 'find' function in Idle, the dialogue closes after the first instance is found.

To find the next instance, one must then use the 'find again' function, rather than the 'find' function. One can also use Ctrl+G, but that may not be intuitive for new users, who may not frequently use keyboard shortcuts.

It would be nice to have a persistent box so that users can simply click 'find' repeatedly to iterate the 'find again' function. We would then have to alter when highlighting happens, as it currently happens only after the box is closed.

I think the relevant code is located in the SearchDialog.py file on line 55.

Unfortunately, I can't figure out how to adjust this myself, as I am a n00b.

Note: I am working on Windows 7 with python ver 2.7.3

I can confirm this behavior. The attached preliminary patch allows the Find dialog to remain open, and is the same for 2.x and 3.x.

Until PEP-434 gets resolved, I won't be able to apply the patch for earlier versions of IDLE. For what it's worth, the applied patch from bpo-13052 changed the behavior of the "Replace All" button so that it doesn't close the dialog box.

If it helps I have confirmed that this patch works great on Python 3.4 and Python 2.7 on the Mac. The code looks very clean and provides a simple fix.

Thanks, Roger.

Unfortunately, this doesn't work for me. I'm running Windows and am using version 2.7.3

For me, nothing is highlighted until the 'find' window closes. This means that if I click 'find', nothing is highlighted even though the text has been found. For what it's worth, hitting 'find' repeatedly does iterate through the instances, I just can't see any of them until the window is closed, at which point I see only the most recent instance.

I should have been more specific in my report; I mentioned line 55 because I think something needs to happen with regard to displaying highlighting while the 'find' window is still open.

System info:
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32

I think I fixed it!

I used some of the code from ReplaceDialog.py to get the highlighted text to display. Thanks to Roger for mentioning that file!

Since the find function now does 'find again', we might want to remove the 'find again' option from the 'Edit' menu.

Side Note: since the 'Replace' dialog includes a 'Find' function, we could remove both the 'Find' dialog and 'Find Again' dialog from the 'Edit' menu, thereby bypassing this issue entirely. We would then need to rename the 'Replace' dialog to 'Find/Replace'. I'm not sure everyone would like that change, though, so I'm not going to implement it here. If anyone thinks it would be useful, I'll create a new thread/issue.

I've never submitted a patch before, so if I've done something incorrectly, please let me know!

(I didn't realize that the patch is identical to the one submitted on bpo-13586).

The issue with the found text not being highlighted is Windows-specific. bpo-13630 discusses that particular problem and it has the same root cause as bpo-14146.

Changing the menu item and dialog boxes goes beyond the original scope of this issue. In the interest of keeping bug-tracking simple, an issue should not be expanded in scope.

Patches are submitted as a unified diff, using "hg diff".

Update for what I wrote in msg185101: The behavior introduced in bpo-13052 which kept the replace dialog open has been reverted by bpo-17625.

There ought to be consistency across the different find/replace dialogs. The replace dialog closes when clicking "close" or "replace all" if there are replacements to be made. Otherwise, clicking "find" in the replace dialog keeps it open.

Other editors, such as Geany, Eclipse, Window's Notepad, and Wordpad, keep their find dialogs open when clicking "Find (Next)". Some of those programs still have a "find next" menu item.

I am in support of letting the find dialog remain open, and possibly relabeling the button to say "find next" instead.

This should allow the 'find' window to stay open. It also circumvents an issue in Windows, wherein highlighted text did not show while the 'find' window was open. The found text should now show as highlighted for any OS (as far as I know; please test). When the find window is closed, the cursor/highlighting is released.

"I am in support of letting the find dialog remain open, and possibly relabeling the button to say "find next" instead."
+1 from me, it drives me nuts to have the dialog close every time a single world is found. I like the find dialog box open then I just escape when I want it closed.

In addition Sarah's patch works well on Mac OS X and Windows. It is fascinating that Sarah found a way to make the high-lighting work even on Windows, I wonder if we could use this technique to fix the debugging problem? As of today I have not heard anything the TK folks since I filed that bug report.

Every other editor I can remember does 'find next'. The current closing annoys me. Also, I prefer wrapping around to the top when the last item is found, rather than having to switch to find [x]up. Windows help does this.

This changes the button's text from "Find" to "Find Again", as per Todd Rovito and Terry J. Reedy's suggestion.

Terry-

There should be a checkbutton option labeled 'Wrap Around'. This is instantiated on lines 7 and 105-111 of SearchDialogBase.py

Admittedly, it is standard practice to have a 'find' function wrap around. I suppose we could have the dialog start up with the 'Wrap around' box checked.

Thoughts?

Note: If we're going to make a change to the 'wrap around' settings, I think we should start a new issue. Wrap around really isn't related to the 'find box closing' issue.

'Find Next' is the actual (and standard) suggestion. It s a trivial change given that you identified the place to make it .

I took a look at both the 'Search' and 'Replace' dialogs and both already have wrap-around present as the default: '[x] Wrap around'. Sorry for not checking earlier.

Having the find window stay open will make it much easier to visually check all the options.*

The Edit menu has 3 find entries
Find ... Cntl+F
Find again Cntl+G
Find selection Cntl+H

I think these menu items should lead to a 'Find' dialog, not a 'Search' dialog. I find the name switch confusing. Both 'find' and 'find_replace' search the text (and both dialogs use SearchDialogBase). That would be a trivial change to add to the patch if everyone agrees. Otherwise it can be a separate issue.

Re-considering whether we still need those 3 entries after this patch would be a separate follow-up issue.

• For automated tests, is the Idle code currently organized in such a way that we can code the following without actually running Idle or showing anything on the screen: create an edit widget or window with some text, create an associated dialog box, set and unset text and options in the box, call an 'action' function, and then check in the edit window that the 'correct' text is highlighted and that the cursor is where it 'should' be? (This of course requires exact specification of 'correct' and 'should'.)

'Find Again' switched to 'Find Next'

I tried the patch against 2.7 and it appears to work, but might introduce another interface problem.

The search dialog opens up as a modal window which disallows the user from changing the text. This may or may not be desirable. The technique of using the "hit" tag for highlighting the search results depends on this modal behavior, otherwise one can edit the text and "spread" the hit tag around.

If you comment out the "grab_set" in Lib/idlelib/SearchDialogBase.py and then disable the colorizer in the editor window by pressing Ctrl+/ then you can spread the hit tag. (You can also disable the colorizer by saving to a file without a .py or .pyw extension).

Should the Search Dialog be modal?

The modal versus non-modal issue, plus the Windows hi-lite issue, may partly explain the current design. It is actually quite usable once understood. The problem is that the current sparse doc does not adequately explain the intention - use ^F once to set the key and find it once, use ^G to find again.

It might help if the Find box itself had a reminder. "Use <bound key> to find the text again after this box closes." I suspect I read and understood the use of ^G once (years ago) and just forgot it due to disuse.

I do not think we should change the current design without more thought and discussion*. The current behavior is intended and not a bug. I suspect that there are people who have learned it and use it as is.

For Notepad++ on Windows, the model search window goes somewhat transparent when one shifts focus to the edit window by clicking on it. However, one must either do this or click [close] on the dialog in order to edit. One can 'find next' either by clicking the Find Next button *or* (when the dialog is closed) by hitting the key bound to find-next. Having to explicitly close the window to edit is a trade-off. It makes it easier to find - find- find without editing. It makes it a bit harder to actually edit after find (an extra action).

The one search thing I do constantly in Notepad++ that is more painful is finding all occurrences in the current file. Find in Files defaults to *.py in the current directory, so one has to replace '*' with the current file name. There should be a Find All button in the Find box (like Notepad++) or a Current File button in the Find in Files box.

*Another issue: The addition of Cut Copy Paste to the *top* of the right-click context menu for the Find in Files *Output* window is a nuisance. It makes it much harder to jump to the file and line of each entry as one now has to slide the mouse much further to get to the
'Go to file/line' entry. I think this should be changed. My point for this issue is that changing features requires thinking about more than just one behavior or use in isolation.

I agree that discussion is a good idea.

Personally, though, I don't want to make the user hit ^F once to set the key and use ^G to find it again. It works well and, for a more advanced user, is great, but it adds to what a user must learn to get up and running in Python and doesn't conform to general conventions. I started using Python 6 months ago, and it took me a while to realize how 'find' worked in IDLE.

For a beginner's IDE, I'd really like to see all of the features accessible through the GUI, and have those features conform to currently accepted standards.

I'm certainly not saying there isn't a better way to do this. I'd love to have a conversation on what that might be.

NOTE: This patch makes 'find' function's functionality consistent with the 'find' function in the 'Replace' menu. If we find a better way to implement the find function, we should extend that functionality to the 'Replace' menu.

I submitted a patch to bpo-14146 that would work around the selection highlighting issue on Windows. It is based on Sarah's idea of replacing the "sel" tags with a tag that remains visible.

There are a lot of ideas floating here about improving the search dialog. Maybe we should take the discussion to idle-dev?

In order to avoid rapidly expanding the issue, I suggest that we limit this issue to the find window remaining open with a "Find Next" button. Does that sound reasonable?

issue_17511_FindNext_rev1.patch keeps the find dialog open and changes the button from "Find" to "Find Next". The applied patch from bpo-14146 corrects the selection tag highlighting issue.

I was wondering does it make sense to commit this patch since it is similar to http://bugs.python.org/issue14146 then put the issue in the pending state as we wait for the TK/TCL fix? It seems more consistent to me since this issue is basically the same highlight problem as 14146. I imagine this is very bothersome for Windows users.

I debated whether or not to leave bpo-14146 as pending or to close it out altogether. I'd rather not let the design decisions of Tk dictate inconsistent cross-platform behavior for IDLE, but I'm willing to hear Tk's rationale and possible fix for that problem.

I would like to commit the current patch and close this issue.

I closed bpo-14146. Same comment will apply here once this is committed. I would like to try the latest patch here before that, and will try to do so tomorrow.

I agree with trying to be consistent across platforms. I am pretty sure that use of multiple personal computers, especially with multiple OSes, is more common than it used to be.

New changeset 73de0794ae71 by Roger Serwy in branch '2.7':
bpo-17511: Keep IDLE find dialog open after clicking "Find Next".
http://hg.python.org/cpython/rev/73de0794ae71

New changeset dac11f143581 by Roger Serwy in branch '3.3':
bpo-17511: Keep IDLE find dialog open after clicking "Find Next".
http://hg.python.org/cpython/rev/dac11f143581

New changeset 67714c4d9725 by Roger Serwy in branch 'default':
bpo-17511: merge with 3.3.
http://hg.python.org/cpython/rev/67714c4d9725

I'm closing this issue as fixed. Thank you for the patch, Sarah.

Immediate highlighting of SearchDialog found text (before closing) does not work on Windows in any current release -- 2.7.8, 3.3.5 (final release) and 3.4.1. Though I continued to use ^F, ^G. Mark Lawrence noticed this and opened bpo-22179. I propose there to use the 'found' highlight, as already used in the replace dialog, for the find dialog also.