WeBuilder 9.5.2.106
These are already mentioned in my 14 Ultimate Feature Requests post, but I believe they deserve special mention...
4a. Find In Files: ALL > Display Full Results Text
The code string in the Search Results Message Frame should be the entire line of code, don't cut this line short. Show the full line of code from the beginning of the line, to (at least) the search query string. If it's a long line, you'll have the adjustable column width (see other suggestion, 4d) to allow viewing it.
( See separate post for these find in files suggestions: http://forums.blumentals.net/viewtopic. ... 94&p=14152 )
4b. Find In Files: ALL > Highlight Query String
The exact query string in the Search Results Message Frame should be highlighted (with yellow, or selectable, background color), or underlined in red (see Dreamweaver).
4c. Find In Files: ALL > Minimal Path Info
Keep unnecessary text in the path column to a minimum by default, if you can get away with just saying the file name, that's all you need. It's the results text that needs to be full length (see other suggestion, 4a). The Search Results Message Frame could possibly have an option (a toggle) to display full path or only folders and/or file names below the project path.
4d. Find In Files: ALL > Adjustable Results Columns
After performing a ā€Search > Find In Files > ALLā€¯, the results string in the Search Results Message Frame should be listed in a separate (and adjustable) column, so that it is left-justified and easy to read. (It should also Remember and restore the column size on the next instance.)
4e. Find in Files: ALL Progress Bar
Show a progress bar during processing, including the number of files searched out of the total (see Dreamweaver.)
6. Find
Please also apply the suggestions for ā€Find In Filesā€™ to the regular Find command.
Feature Request: 'Find In Files' - Better Results Display
Moderator: kfury77
Forum rules
Please follow these guidelines when posting feature requests. This will help to increase the value of your contribution.
Please follow these guidelines when posting feature requests. This will help to increase the value of your contribution.
- Do not create new topics for already requested features. Add your comments to the existing feature request topics instead;
- Create separate topic for each feature suggestion. Do NOT post a number of non-related feature suggestions in a single topic;
- Give your topic a meaningful title. Do NOT create topics with meaningless titles, such as "My Suggestion" or "My Problem".
-
CaliforniaJerry
- Posts: 88
- Joined: Sat Aug 01, 2009 4:48 am
- Location: Mountain View, CA
- Contact:
Feature Request: 'Find In Files' - Better Results Display
Last edited by CaliforniaJerry on Mon Aug 10, 2009 9:43 pm, edited 3 times in total.
Re: Feature Request: 'Find In Files' - Better Resluts Display
like those ideas!
-
johnradams
- Posts: 12
- Joined: Fri Aug 21, 2009 3:54 am
Re: Feature Request: 'Find In Files' - Better Results Display
Excellent suggestions.
Note that many of CaliforniaJerry's points are consistent with the idea that often (but not always), a FindInFiles operation is used to track down some small snippet across many files. The search results may include many false positives. Enhancing the results section (as previously suggested) would help the user to decide if a given file needs to be opened for further investigation.
Also, on the point of taking the user to a slightly incorrect file position after the file has been edited, I agree that getting "close" is just fine. Especially if you consider that a FindInFiles search may well be used to make a minor change in a lot of places across a lot of files -- and a "minor" change is unlikely to make a big difference in the location of the search results. In other words, and speaking generally, I contend that the size of the edit operation for each file is inversely proportional to the number of edits that you are making based on the files listed in the search results. So, for large FindInFiles operations, the edits are probably small -- and thus minimally affect the location.
Note that many of CaliforniaJerry's points are consistent with the idea that often (but not always), a FindInFiles operation is used to track down some small snippet across many files. The search results may include many false positives. Enhancing the results section (as previously suggested) would help the user to decide if a given file needs to be opened for further investigation.
Also, on the point of taking the user to a slightly incorrect file position after the file has been edited, I agree that getting "close" is just fine. Especially if you consider that a FindInFiles search may well be used to make a minor change in a lot of places across a lot of files -- and a "minor" change is unlikely to make a big difference in the location of the search results. In other words, and speaking generally, I contend that the size of the edit operation for each file is inversely proportional to the number of edits that you are making based on the files listed in the search results. So, for large FindInFiles operations, the edits are probably small -- and thus minimally affect the location.