DIE DIE DIE DIE DIE
Dec. 14th, 2006 09:56 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
I should start an Eclipse UI Rant blog. I am *continually* finding serious issues with this IDE that are so... *braindead* that I wonder how the hell it got the rep it has for being so good. Seriously. It's like they took off sprinting before they could crawl, so it's got all these whiz-bang features (some of which are great functionality - if you can either find or use them...), but INCREDIBLY basic stuff is either borked or just plain missing. Fer instance, the two I ran into tonight. If anyone has a suggestion for these very trivial things, I'd appreciate it. "Install Mylar!" is not an answer, just to make that clear. If I wanted to learn a new UI tonight (because each plug-in and feature seems to bring it's own *special* uniqueness to the table) for such simple things, I wouldn't have a deadline in the morning that I need to meet.
1) Package Explorer. Filters. Search. WTF? I have a massive project I need to find all the tests in. Filenames are *not* of the form TestFoo.java or FooTest.java. They are instead inside folders named 'test'. (Don't look at me, I didn't write the damned things.) They are nested anywhere from 6-11 layers deep. There are many such folders. I would like to find them.
- Filters are subtractive *only*. I can remove unknown cruft from a list, but it can't be used, that I can see, to find known items. There is no way to add a 'not' operator to the search string to get it to filter out everything not conforming to the string. Regex? What's that? We'll just fake it! Bollocks. If this *is* using regex, it's not a format I'm familiar with.
- Search (Files) does positive hits... but it apparently won't search folder names, just files. I'm sorry, but what the fuck? I can't search folder names?
While we're on this, why, oh WHY does filtering occur within the Package Explorer, but Search pop up it's own handy dandy pane? They both end up with tree views, they both show results from a search (filter == subtractive search)... why the two interfaces? So close guys... so close.
The combination of the above two means that it is almost impossible to search for known names of folders easily. This can't be right. Point me to what I'm missing, please...
Update: `find . -name \*[T,t]est\* | sort > tests` in the terminal did the trick *so* easily... now if there were just some way to get that info into the Bookmarks...
2) Bookmarks. See above scenario. Now that I'm stuck (apparently) manually searching for the folders, I'd like to tag them as bookmarks so I can get back to them quickly. Easy, right? Basic functionality in any IDE, right? Not so fast there, buckaroo...
I finally found where the hell they were buried. (BTW, the Help system says to: Open the Resources Perspective to allow the Bookmarks view to appear in the Window -> Show Views submenu. Or, you could Window -> Show View -> Other and then look under General from any perspective...) I can bookmark a file. I can bookmark a specific line *within* a file. I cannot bookmark a folder. Again, W. T. F? Why is there this insistence on treating some disk-based resources differently? Hell, why is there an insistence on making two classes of visual elements in the underlying model? Resources... visual element... bookmarkable, right? Nope. Again, it seems you guys missed it by *this* much.
Someone throw me some waterwings before this boat anchor takes me down.
1) Package Explorer. Filters. Search. WTF? I have a massive project I need to find all the tests in. Filenames are *not* of the form TestFoo.java or FooTest.java. They are instead inside folders named 'test'. (Don't look at me, I didn't write the damned things.) They are nested anywhere from 6-11 layers deep. There are many such folders. I would like to find them.
- Filters are subtractive *only*. I can remove unknown cruft from a list, but it can't be used, that I can see, to find known items. There is no way to add a 'not' operator to the search string to get it to filter out everything not conforming to the string. Regex? What's that? We'll just fake it! Bollocks. If this *is* using regex, it's not a format I'm familiar with.
- Search (Files) does positive hits... but it apparently won't search folder names, just files. I'm sorry, but what the fuck? I can't search folder names?
While we're on this, why, oh WHY does filtering occur within the Package Explorer, but Search pop up it's own handy dandy pane? They both end up with tree views, they both show results from a search (filter == subtractive search)... why the two interfaces? So close guys... so close.
The combination of the above two means that it is almost impossible to search for known names of folders easily. This can't be right. Point me to what I'm missing, please...
Update: `find . -name \*[T,t]est\* | sort > tests` in the terminal did the trick *so* easily... now if there were just some way to get that info into the Bookmarks...
2) Bookmarks. See above scenario. Now that I'm stuck (apparently) manually searching for the folders, I'd like to tag them as bookmarks so I can get back to them quickly. Easy, right? Basic functionality in any IDE, right? Not so fast there, buckaroo...
I finally found where the hell they were buried. (BTW, the Help system says to: Open the Resources Perspective to allow the Bookmarks view to appear in the Window -> Show Views submenu. Or, you could Window -> Show View -> Other and then look under General from any perspective...) I can bookmark a file. I can bookmark a specific line *within* a file. I cannot bookmark a folder. Again, W. T. F? Why is there this insistence on treating some disk-based resources differently? Hell, why is there an insistence on making two classes of visual elements in the underlying model? Resources... visual element... bookmarkable, right? Nope. Again, it seems you guys missed it by *this* much.
Someone throw me some waterwings before this boat anchor takes me down.
(no subject)
Date: 2006-12-16 05:42 am (UTC)I'm looking for methods in a list of known files of the form name=test*. I can...
1) Search File (Content) for test* and get a gazillion hits in files I care nothing about (the list is a small subset of a project with a few thousand files)
2) Inspect each file in the Search pane results manually.
And then I noticed the Outline pane sitting over there... it would be rather nice to be able to say "Filter to show only items with test* for name". Opening a file in the editor would immediately show me if the file was a hit or not - I wouldn't have to even have the Outline pane be more than a few chars wide. As it is now, it has to be wide enough for me to be able to manually traverse the list and check. While it is quick, with the positive filtering, it'd be nearly an instantaneous determination, without having to change cursor focus from the Search pane.
(no subject)
Date: 2006-12-16 06:07 am (UTC)Heck, if I had an additive filter, I could just say "Filter for all .java files within these packages, now show just all methods starting with test*, and oh, by the way, give me just the declarations." by building up two simple ones. Badabing, badaboom, I've got precisely the information I was looking for.