Community
Participate
Working Groups
The Open Resource dialog currently only accepts patterns for a file name (e.g. "plugin.*"). It should also match patterns for a folder path. E.g. I would expect that the pattern "*jdt.ui*/plugin.xml" filters the folders list to only show folders whose name matches the sub-pattern "*jdt.ui*", i.e. "org.eclipse.jdt.ui", "org.eclipse.jdt.ui.tests", etc.
This is a very desirable feature. Might I suggest that instead of path/to*Filename as a pattern, spaces are allowed to separate independent expressions. For example, in the CDT world where you want to open a Makefile, a user might: 1) ctrl-shift-R 2) Type Makefile 3) See many many entries, so type space and start typing part of the path. The dialog would then show the files matching the intersection of the two expressions (+any files/paths which match the full expression including the space...)
Created attachment 100887 [details] First patch for open resource using Paths Patch to add support for opening resources using Paths. This patch adds a couple additional features: 1) Relative paths are treated as relative to the currently open editor's container or current selection if there isn't a currently open editor 2) After sorting alphabetically, I sort files within the current container before other files in the Workspace. It turns out, from my comment #2, that a search engine style with multiple keywords would require further changes... Any feedback would be much appreciated! James
Created attachment 100900 [details] Patch 2 Previous patch included a change to an unrelated file... This patch is against version 1.19 in the Eclipse CVS (as 1.19 is not quite as compatible with 3.3.x)
Please adjust the target milestone, so it does not point at a closed milestone in the past.
(In reply to comment #4) I don't think Krzysztof is still working on this. Assigning back to inbox.
Krzysztof left the team some time ago. I'm removing the target milestone.
This is a much requested feature -- especially from guys coming from emacs... It would be good if this patch could be picked up / commented on by one of you committers.
Markus, I left the assignee on purpose. I'm waiting for the decision who in UI will take over this stuff. When I have it, I will move all Krzysztof's bugs to the person and I won't bother the UI triage monkey.
Reassigning to Susan.
Hi Susan, Szymon et al., Is it possible to get some feedback on this patch. This is a much wanted feature for people coming from emacs, and we've been using this patch successfully here for some time... It would be really great for this to get into 3.5 Cheers, James
Hi, James. Thanks for the patch. This bug got reassigned as we were wrapping up 3.4, hence it fell through the cracks for a little while (longer). I don't have a lot of time for platform UI bugs during 3.5, but I am trying to review patches for a day or two during M3 and M4. I'll mark this M4. In the meantime, I'd like to make sure that the patch is consistent with the original suggestion, or at least that we agree on the requirements. >It turns out, from my comment #2, that a search engine style with multiple >keywords would require further changes... can you confirm that your patch implements the scheme Markus originally suggested (being able to supply patterns in a "folder path/file" format? >This patch adds a couple additional features: >1) Relative paths are treated as relative to the currently open editor's >container > or current selection if there isn't a currently open editor >2) After sorting alphabetically, I sort files within the current container >before other files in the Workspace. I'd have to try this out to see how it plays. #2 sounds reasonable, I'm not sure how #1 will play, if it will be confusing or just do the right thing. Any thoughts, Markus?
Hi Susan, thanks for the prompt reply. (In reply to comment #11) > >It turns out, from my comment #2, that a search engine style with multiple > >keywords would require further changes... > > can you confirm that your patch implements the scheme Markus originally > suggested (being able to supply patterns in a "folder path/file" format? Indeed. You can type things like: /project_name/some_folder/*/foo.java or */some_folder/*/foo.java or just foo.java as before. Basically "/" is the workspace root which allows you to restrict to a certain project if you wish. Alternatively you can filter on any part of the path. > I'd have to try this out to see how it plays. #2 sounds reasonable, I'm not > sure how #1 will play, if it will be confusing or just do the right thing. Any > thoughts, Markus? The reason for #1 is that in the C world where nearly every direcoty has a file called "Makefile". When the user wants to editor a Makefile, they want the one that corresponds to the current editor which is usually the one in the current directory. In emacs (/other text editors) many users are also used to opening a file 'relative' to the currently open file. i.e. they do ctrl-shift-r and type ../some_other_file. Have a go with the patch and see what you think, I guess. Basically it has the same behaviour as open-resource does currently it simply now considers a path as well if the user desires :). BTW I believe BUG239588 is a dup of this -- though pwebster was 'excluded' from the list of notifiees when I submitted the comment to that effect. If you have any issues with the patch i'm quite happy to address them!
*** Bug 239588 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > I'd have to try this out to see how it plays. #2 sounds reasonable, I'm not > sure how #1 will play, if it will be confusing or just do the right thing. Any > thoughts, Markus? Both additional features from comment 2 sound a bit scary at first, since the dependency on the editor input might no be obvious to the user. But the "Makefile" example sounds compelling, so I would give it a try. Note that "plugin.xml" file in plug-in development is a similar case. You often want to open the manifest for the editor input's enclosing project. Since this patch adds nontrivial functionality to the Open Resource dialog, you should also write a help page and set the dialog's help context id, such that users can quickly read more about how the dialog works (cf. the Open Type dialog). I would also adapt the first label in the dialog, e.g. to "Enter prefix or pattern for resource name or path (wildcards: ?, *):".
Moving target as M4 has shipped.
marking UI (so it shows up in my lists)
Dani, do you have time to look at this? I think you are in a better position to evaluate this, and I think you own open resource now?
>Dani, do you have time to look at this? Sorry no time. The question is also whether we make the suggested changes/additions mentioned in comment 14 or whether we wait for a new patch from James.
(In reply to comment #18) > >Dani, do you have time to look at this? > Sorry no time. The question is also whether we make the suggested > changes/additions mentioned in comment 14 or whether we wait for a new patch > from James. Woops, this slipped. I'll try to make some time this weekend.
removing M6 milestone, there's no way I can shift attention to this right now (sorry). If there is someone else who cares enough to shepherd this into the release, please take this bug.
James, if you add another patch, please make the fields you added private (rather than protected). And you cannot remove the old constructor of ResourceFilter, since it is API. The way you store the filter in createFilter() is problematic. It breaks as soon as subclasses override the method. You should probably add a protected FilteredItemsSelectionDialog#getCurrentFilter() method and use that (give little guarantees in the API and check for null when accessing). Check that Navigate > Go To > Resource... works in the Package Explorer.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
*** Bug 290121 has been marked as a duplicate of this bug. ***
Created attachment 151223 [details] patch 3 Patch update for HEAD. The previous patch only extended FilteredSelectionDialog to allow matching paths. This patch adds 'distance' to the sort criteria. Distance is defined as the count of the number of directories you would need to change (using cd for example) where you're only allowed to change one directory at a time. Therefore ctrl-shift-R: plugin.xml should give you the plugin.xml that's nearest to your current selection i.e the one in the current project. It's important to note that the file name sort *still* dominates. i.e. this distance metric is only used where file names are identical. The result should be that more relevant entries are near the top rather than the currently arbitrary shortest fullPaths first approach. Review / feedback / committing would be appreciated :) Note there's already an existing bug 193911 requesting help for the Open Resource dialog. (In reply to comment #21) > James, if you add another patch, please make the fields you added private > (rather than protected). And you cannot remove the old constructor of > ResourceFilter, since it is API. The attached patch should be API clean (I've got API tooling enabled). > Check that Navigate > Go To > Resource... works in the Package Explorer. This should now work.
*** Bug 295327 has been marked as a duplicate of this bug. ***
*** Bug 210761 has been marked as a duplicate of this bug. ***
So are there any obstacles to committing this patch in?
(In reply to comment #27) > So are there any obstacles to committing this patch in? The obstacle at this point is simply making time to review...I'll mark this M6 to keep it on the radar. (My M5 is already overcommitted). Markus, since you are a committer now, if you want to take this bug, I would have no objections.
OK, I'll take this. (In reply to comment #14) > Since this patch adds nontrivial functionality to the Open Resource dialog, you > should also write a help page and set the dialog's help context id, such that > users can quickly read more about how the dialog works (cf. the Open Type > dialog). Any help for this would be appreciated (bug 193911). I don't want to ship this change without proper doc.
(In reply to comment #29) > OK, I'll take this. thanks, Markus. > > (In reply to comment #14) > > Since this patch adds nontrivial functionality to the Open Resource dialog, you > > should also write a help page and set the dialog's help context id, such that > > users can quickly read more about how the dialog works (cf. the Open Type > > dialog). > > Any help for this would be appreciated (bug 193911). I don't want to ship this > change without proper doc. I took this bug for myself for 3.5M6. Seems like a fair swap!
Markus, I assumed you are ok if the doc lags behind a bit? I could try to get skeletal context help in for M5 and flesh it out later?
(In reply to comment #31) > Markus, I assumed you are ok if the doc lags behind a bit? I could try to get > skeletal context help in for M5 and flesh it out later? Sorry, I didn't get to this in time and don't want to risk stability now. I'll release it in M6 and add the docs (which should take less time if I do it right after the code review).
I've still too much on my plate, have to move this to M7. I verified that we don't need any of the APIs the patch adds.
Just throwing my voice in the chorus here if it makes a difference. As a Django/Python developer I have about 10 files named "models.py" and I would love to able to something like "*db/*models*. CTRL+Shift+R is a great shortcut, but it's somewhat less effective when your filenames don't contain module/app prefixes.
Interesting idea. Isn't the "**" commonly used for matching multiple path segments?
Now that M6 is out the door, it would be great if you could review this for commit Markus. It'd be great to get this into Helios!
Created attachment 162730 [details] Patch 4 Released to HEAD with a few changes: - made new members private - replaced calls to IPath#toOSString() with IPath#toString(). The Open Resource dialog deals with workspace-relative paths, and for those, Eclipse uses '/' as separator on all platforms. - made context more predictable by only getting it from the active part (if an editor has focus, take the editor input, otherwise take the selected element if there is one) - fixed problem with initialization of resourceRelativePattern in the ResourceFilter: IPath#append(String) only works fine if the argument is really a valid path. To avoid problems with invalid paths (e.g. path "abc:" on Windows), I now append the pattern manually (unless it starts with a '/'). - fixed ResourceFilter#pathDistance(IContainer): It needs to return a big distance when no segments match (otherwise the sum of their segment counts is used for sorting, and that's wrong) - reverted the change in ResourceFilter#isConsistentItem(Object). I don't see why that should be necessary, and it looked wrong. - moved pathDistance(..) into the Comparator
Fixed.
I've released an additional fix for I20100323-0800 to avoid an NPE when the history cache contains files with the same name.
(In reply to comment #37) > Created an attachment (id=162730) [details] > Patch 4 Thanks Markus!! The changes all look good to me.
Patterns that start with "*" did not only match file names, but also folder paths. I found that confusing, and it's also a performance hit for simple file name patterns. For I20100406, I've released a follow-up fix that separates folder path and file name patterns at the last '/', and that improves performance in other places by avoiding resource.getFullPath().toString() as much as possible.
One of the things that used to work, but doesn't with the patch on HEAD is the ability to open files relative to that in your current editor. This was the primary driver for me implementing the feature, users, editing a file do: ctrl-shift-r ./ and open resource shows the set of files in the current directory and below. Currently it's empty.
(In reply to comment #42) > Currently it's empty. I've fixed the support for relative paths (starting with ./ or ../) in HEAD. It already worked for ./* or ./xxx but the rest was broken. > [..] the current directory and below. The "and below" part is problematic. We need to offer a way to match only in the current directory, and ./xxx does that. In 3.7, we could look into Ant-like patterns, where ** could expand to zero or more directories.
> The "and below" part is problematic. I know it's a hack, but you can use "../*/abc" as a workaround to match files starting with "abc" in the current folder or below ("*" matches 1 or more directories, so "./*/abc" would not match in the current directory).
Excellent, thanks markus! Will have a look tomorrow, but that certainly fulfils the main use-case we have of opening the Makefile in the same directory as the source.
Verified in I20100425-2000 on Windows 7. While testing I really missed the feature that shows the matching characters (bug 264840).
