classification
Title: Idle find function closes after each find operation
Type: enhancement Stage: resolved
Components: IDLE Versions: Python 3.4, Python 3.3, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: 14146 Superseder:
Assigned To: roger.serwy Nosy List: Kuchinsky, Sarah, Todd.Rovito, python-dev, roger.serwy, terry.reedy
Priority: normal Keywords: patch

Created on 2013-03-21 21:47 by Kuchinsky, last changed 2014-08-16 01:17 by terry.reedy. This issue is now closed.

Files
File name Uploaded Description Edit
issue17511.patch roger.serwy, 2013-03-23 22:13 review
SearchDialog.py Kuchinsky, 2013-03-26 19:15 SearchDialog file updated to keep find window open and highlight relevant text
issue17511_v2.patch Sarah, 2013-04-08 02:57 review
issue17511_FindAgain.patch Sarah, 2013-04-08 15:26 review
issue_17511_FindNext.patch Sarah, 2013-04-08 18:35 review
issue_17511_FindNext_rev1.patch roger.serwy, 2013-05-21 03:33 review
Messages (26)
msg184915 - (view) Author: S (Kuchinsky) Date: 2013-03-21 21:47
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
msg185101 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2013-03-23 22:13
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 PEP434 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 issue13052 changed the behavior of the "Replace All" button so that it doesn't close the dialog box.
msg185113 - (view) Author: Todd Rovito (Todd.Rovito) * Date: 2013-03-24 04:34
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.
msg185278 - (view) Author: S (Kuchinsky) Date: 2013-03-26 15:58
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
msg185291 - (view) Author: S (Kuchinsky) Date: 2013-03-26 19:15
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!
msg185448 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2013-03-28 13:58
(I didn't realize that the patch is identical to the one submitted on issue13586).

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

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".
msg186262 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2013-04-08 02:12
Update for what I wrote in msg185101: The behavior introduced in #13052 which kept the replace dialog open has been reverted by #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.
msg186263 - (view) Author: Sarah (Sarah) * Date: 2013-04-08 02:57
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.
msg186272 - (view) Author: Todd Rovito (Todd.Rovito) * Date: 2013-04-08 04:19
"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.
msg186276 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-04-08 05:23
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.
msg186307 - (view) Author: Sarah (Sarah) * Date: 2013-04-08 15:26
This changes the button's text from "Find" to "Find Again", as per Todd Rovito and Terry J. Reedy's suggestion.
msg186314 - (view) Author: Sarah (Sarah) * Date: 2013-04-08 16:00
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.
msg186319 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-04-08 17:19
'Find Next' is the actual (and standard) suggestion. It s a trivial change given that you identified the place to make it .
msg186325 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-04-08 18:28
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'.)
msg186327 - (view) Author: Sarah (Sarah) * Date: 2013-04-08 18:35
'Find Again' switched to 'Find Next'
msg186373 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2013-04-09 04:46
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?
msg186382 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-04-09 06:16
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.
msg186436 - (view) Author: Sarah (Sarah) * Date: 2013-04-09 15:49
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.
msg186609 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2013-04-12 05:50
I submitted a patch to #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?
msg189721 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2013-05-21 03:33
issue_17511_FindNext_rev1.patch keeps the find dialog open and changes the button from "Find" to "Find Next". The applied patch from #14146 corrects the selection tag highlighting issue.
msg190127 - (view) Author: Todd Rovito (Todd.Rovito) * Date: 2013-05-27 02:42
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.
msg190270 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2013-05-29 03:58
I debated whether or not to leave #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.
msg190272 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-05-29 04:36
I closed #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.
msg190944 - (view) Author: Roundup Robot (python-dev) Date: 2013-06-11 04:08
New changeset 73de0794ae71 by Roger Serwy in branch '2.7':
#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':
#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':
#17511: merge with 3.3.
http://hg.python.org/cpython/rev/67714c4d9725
msg190945 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2013-06-11 04:11
I'm closing this issue as fixed. Thank you for the patch, Sarah.
msg225381 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-08-16 01:17
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 #22179. I propose there to use the 'found' highlight, as already used in the replace dialog, for the find dialog also.
History
Date User Action Args
2014-08-16 01:17:57terry.reedysetmessages: + msg225381
2013-07-29 20:18:27r.david.murraylinkissue18590 dependencies
2013-06-11 04:11:31roger.serwysetstatus: open -> closed
resolution: fixed
messages: + msg190945

stage: commit review -> resolved
2013-06-11 04:08:17python-devsetnosy: + python-dev
messages: + msg190944
2013-05-29 04:36:15terry.reedysetmessages: + msg190272
stage: patch review -> commit review
2013-05-29 03:58:42roger.serwysetmessages: + msg190270
2013-05-27 02:42:22Todd.Rovitosetmessages: + msg190127
2013-05-21 03:33:27roger.serwysetfiles: + issue_17511_FindNext_rev1.patch

messages: + msg189721
2013-04-12 05:50:19roger.serwysetdependencies: + IDLE: source line in editor doesn't highlight when debugging
messages: + msg186609
2013-04-09 15:49:12Sarahsetmessages: + msg186436
2013-04-09 06:16:23terry.reedysetmessages: + msg186382
versions: + Python 3.3, Python 3.4
2013-04-09 04:46:10roger.serwysetmessages: + msg186373
2013-04-08 18:35:22Sarahsetfiles: + issue_17511_FindNext.patch

messages: + msg186327
2013-04-08 18:28:30terry.reedysetmessages: + msg186325
2013-04-08 17:19:38terry.reedysetmessages: + msg186319
2013-04-08 16:00:44Sarahsetmessages: + msg186314
2013-04-08 15:26:54Sarahsetfiles: + issue17511_FindAgain.patch

messages: + msg186307
2013-04-08 05:23:25terry.reedysetmessages: + msg186276
2013-04-08 04:19:56Todd.Rovitosetmessages: + msg186272
2013-04-08 02:57:32Sarahsetfiles: + issue17511_v2.patch
nosy: + Sarah
messages: + msg186263

2013-04-08 02:12:49roger.serwysetnosy: + terry.reedy
messages: + msg186262
2013-03-28 13:58:32roger.serwysetresolution: works for me -> (no value)
messages: + msg185448
2013-03-26 19:15:49Kuchinskysetfiles: + SearchDialog.py
resolution: wont fix -> works for me
messages: + msg185291
2013-03-26 15:58:53Kuchinskysetresolution: wont fix
messages: + msg185278
versions: - Python 3.2, Python 3.3, Python 3.4
2013-03-24 04:34:13Todd.Rovitosetmessages: + msg185113
2013-03-24 01:59:41Todd.Rovitosetnosy: + Todd.Rovito
2013-03-23 22:13:48roger.serwysetfiles: + issue17511.patch

type: enhancement
assignee: roger.serwy
versions: + Python 3.2, Python 3.3, Python 3.4
keywords: + patch
nosy: + roger.serwy

messages: + msg185101
stage: patch review
2013-03-21 21:47:32Kuchinskycreate