DIE DIE DIE DIE DIE

[kickaha]

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.

Comments

[actsofcreation.livejournal.com]

One of the things Eclipse suffers from is that it doesn't support crazy well. What this frequently means is that if 99% of the Java world behaves in a particular way ideomatically, then Eclipse supports that quite well and other behaviors poorly. Since 99% of the javaworld writes their UnitTests as Test* or *Test you are SOL.

[kickaha.livejournal.com]

So I take it then that that means that the above issues with search/filter and bookmarking (regardless of the specifics of the scenario of wackily named files) are, without resorting to something like Mylar, truly not supported? Bugger.

Any insights on to why folders, while visual and important semantic elements that are otherwise reasonably treated, are utterly left out of the loop in these basic tasks?

[actsofcreation.livejournal.com]

Part of it is you are misunderstanding sematically what 'Search Files' is. It isn't a search over resource names, but a search of the contents of files. Since directories are not things which have contents in the sense files do, it naturally doesn't search them.

What you really want (IMHO) the 'everything matching' in addition to the 'everything not matching' filter functionality. That being absent is a good point, and one I can get behind.

[kickaha.livejournal.com]

Actually, I was ignoring the first search box 'Contains string' as what you noted, within files, and was using the second text box 'Filename pattern'. Yes, it says specifically 'filename' and not 'file or folder name' but it was quite surprising since it differs from what I would think would be reasonable. I found that if I left the first field blank, it simply ignored file contents, and searched solely on file (but not folder!) name.

And yes, that's precisely the sort of filtering functionality I'd like - filtering out is useful, but filtering *in* is, IMO, even more so for code diving. "Okay, I know it has something like 'blah' in the name... could be a file, could be a folder... oh hell, just give me all possible matches."

[actsofcreation.livejournal.com]

I will be sure to raise it at the 'Why Eclipse sucks' panel at Eclipsecon

[kickaha.livejournal.com]

*laugh* I forgot about that. :D I'll see what else I can add to your list. ;)

[kickaha.livejournal.com]

Your point, however, about Search Files being first and foremost a file *content* searching tool is taken. The behavior when leaving the content field blank then, however, is... to be accepted as a happy accident, and not much more?

[actsofcreation.livejournal.com]

Not really... ask yourself this about every file: does it contain 'epsilon' the empty string? I would say yes. Thus every file matches. Does a directory contain the empty string... no, because directories don't contain strings, they contain files.

[kickaha.livejournal.com]

What I meant was that the fact that the Search File Contents *can* be used for searching by file name at all is a happy, unintended consequence of putting in a null content string. It wasn't *intended* to be a filename search feature, and the fact that it can be used as one is strictly happenstance... and shouldn't be really used as such, probably.

Which means that there isn't really *any* proper file/folder/package name positive-filtering feature in the Package Explorer, only subtractive filtering. Beezarre.

Optimally, I'd like to see the filtering setup dialog allow for a simple exclude/include toggle. There's really not enough room in the PE pane title (or toolbar) from how I've seen most people have it set up to add a ready text field for positive name filtering, unfortunately. (Think iTunes search field. Type a sub-string, instant results. Clear to resume full view.) In any case, the point is to get the view culled down to just those elements of interest, *with* the folders leading down to them. The results returned by Search, for instance, are alphabetized by filename, not sorted by path - that surprised me. If I'm going code diving, I'm probably *much* more interested in how the pieces hang together semantically in the packaging structure than I am by what the file is named. The file name is the lowest level of organizational detail prior to hitting the code, but the packaging gives me the conceptual placement in the project. At the very least, I would have left-aligned the paths with padding after the filenames for easy visual comparison, or added a 'sort by path' option.

[actsofcreation.livejournal.com]

Remember though... packages you can search for :) Just use the java search.

[kickaha.livejournal.com]

Okay, so let me get this straight.

Packages, files, and folders are all containers that are used to semantically define and group code at different levels of granularity. Java's directory-based namespaces are a perfect example of this.

This concept is continued in the GUI, as they are all presented in the Package Explorer as hierarchical elements, ending at files as leaves. (Files then become the roots of the Outline pane, but we won't get into why that seems like an artificial boundary...)

To search for packages by name, you use Search Java. To search for files by name, you use Search File (Contents), but leave the content null. There's no way to search for folders by name.

That about cover it?

[actsofcreation.livejournal.com]

Pretty much... here's what it comes down to, you get:

The ability to search for string regexes in files.
The ability to search for language artifacts.

What you don't get:
The ablility to search for arbitrary resources (aka files/directories).

Should you be able to do a resource search: yes, but right now you can't.

[kickaha.livejournal.com]

Well bugger.

At least I know I wasn't completely missing something (else) obvious.

So I guess there's two items for the panel: additive filtering in the standard filter widget, and resource searching. :) I'll hold off on the "but they're all just scoping delimiters!" item for another day. :D

[kickaha.livejournal.com]

More support for a positive filtering functionality...

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.

[kickaha.livejournal.com]

Search Java for methods would also get me the large number of hits, even if it was pared down to just Declarations. :)

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.

[jinasphinx.livejournal.com]

Do you like NetBeans, then? I'm doing raw beginner stuff right now (working my way through Head-First Java, only 100 pages in) so it's just command-line, but for when I do hit the IDE stage, I'd welcome any recommendations.

[kickaha.livejournal.com]

Haven't used it. I suspect that Eclipse really is the best game in town, I guess I was just expecting a higher caliber of polish given the hype surrounding it. *shrug*

I need to keep better track of these issues, to be honest. Little things keep biting me like...

In the Package Explorer, it's a tree of disclosure triangles. Open waaaaaay down into a tree to find what you need. Decide you'd like a higher-level view for a moment. Close the top triangle only. Now open it again. Voila! It lost all the state below that, and you get play find-the-file all over again. Annoying. Lesson learned: never close anything.

Similarly, also in PE, because things get very deeply nested, you have to scroll the pane to the right. (Or resize it so it takes up most of your workspace, but now why not just make it a damned window, you know?) Start traversing down, use the keyboard because it's faster than the mouse, and *snap* the scrollbar goes back to the left. Scroll right, click on the next triangle, and *snap* there goes the damned scrollbar again, hiding what you just told it you want to look at. Annoying. Lesson learned: you have to manually manage your views... continuously.

It's little crap like this that makes me feel like I'm fighting with it every step of the way.