[CLOSED] Exclude files from Find in Files operations #6351
Comments
|
|
|
This is awesome :) But I think we can improve the filters management UI a bit more since I didn't found it that intuitive. I think that when you select An alternative could be a 2 steps UI, The first dialog opens where you select a filter and after clicking |
|
I think the intent was to keep this simple, so you don't "manage a list of filters" - we just have a history of the filters you've used. But I think what's confusing is that when you choose "Edit filter", it feels like you should be editing the current filter, but instead it adds a new filter. I wonder if it would be better to make it so "Edit filter" really does edit the last selected filter, and there's a separate "New filter" for creating a new one. |
|
A couple other thoughts on the UI:
|
|
Actually, another thought...what if when you hover over a filter in the list, it gets icons next to it - "x" to delete, pencil to edit? This would be similar to what we do in the Recent Project dropdown. Then we would just need a "New filter" entry at the bottom to create a new one. |
|
I see. I thought I was editing the filter I selected, but it just creates a new one. I like |
|
/cc |
|
The idea of splitting Edit Filter from New Filter seems reasonable... although it does mean that the list isn't really a history list anymore since it might no longer contain the filter you just recently used (if you've edited it since then). It seems like this creates a pitfall -- it could lead to the list only ever having 1 thing in it (which the user repeatedly edits as needed), losing the benefit of having a list in the first place. Maybe one way around that would be to keep the current UI (Edit only), but don't add repeated edits as separate items to the history list -- only add something when you actually run a search using it... Re backslashes: my only concern with that is that it'd be inconsistent with the rest of Brackets. We display paths with forward slashes everywhere in the UI, and other places that do matching (e.g. Quick Open, the preferences system) don't do this translation. |
|
In the long run (i.e. user story linked above) I think we should do the larger UI Tom mentioned, since it has the benefit that you can name common filters. Right now, it's very hard to represent the arbitrary filter strings in a compact way, so allowing "friendly names" feels like a big plus. Especially since the list of filters is global across all projects... |
|
Makes sense to keep the other functionality separate. I don't think the change you're suggesting to Edit fixes the fundamental problem, which is that "Edit" sounds like it should modify something rather than creating a new thing. I agree that if we split it into New/Edit it won't feel as much like history, but I think it actually makes it easier for the user to map what they want onto the functionality - tweaking a filter vs. creating a new one. It does make it harder to base a new filter on an existing one, though. You're right about backslashes - I had forgotten that we don't really deal with them anywhere in the UI. I guess no one's complained so far :) |
|
If the edit will be in a different story, that is good. I do think that On the complete UI, we could duplicate filters, and even make filters to be used only in the current project. |
|
Hmm, I think we have a conceptual model mismatch going on. The original proposal for the first-pass story was: you have one filter, which you can edit, and that's it. Then we extended it by saying there's also a history of previously-used filters; but what you're editing is always the one, current filter. You're not 'making a new filter' when you modify that filter, but the history list does grow since the once-current value is now a previous value. If that model isn't clear in this UI -- and it sounds like it isn't -- we could try to make it less ambiguous, e.g. by moving Edit to the top, adding a "History" heading to the list below it, and only adding to the history list when you execute the search... But I wonder if we should actually go back to the original plan at this point -- one filter, no list at all. That might be better than putting more effort into this temporary history/MRU list that's actually going to get replaced with a full filter-management UI in the near future. Or a third option would be to say we shouldn't ship this at all until the full UI can be implemented... |
|
|
|
Yes I think we should simplify it for now. We could rename "Edit Filter" to "Edit Filter List" to make it clearer. |
|
|
|
|
|
Updated description |
|
Hmm, one thing I've noticed now that I'm using the feature more is that the actual globmatch filtering is fairly slow -- the getAllFiles() phase of the search takes 5-6 seconds now, vs. just 35 ms without any filters. The more filters you add, the slower; I have about 10 in my test. I'm going to look into whether that can be improved... |
|
This is becoming problematic... I'm able to get about 10x better performance (which seems good enough) by preprocessing the glob expression into a regexp with Minimatch.makeRe()... but unfortunately the implementation seems buggy and doesn't match the same strings. I.e. if |
|
If we roll our own regexp conversion using a simpler syntax, we can get a 100x speedup, so at least there's that path forward if we need it. I'll continue to investigate the Minimatch issues though... |
|
Personally, I don't think it's important that we support everything minimatch does. If we just support the kinds of common cases that you've outlined, I think we'd be fine. |
|
Example of minimatch makeRe() bug: isaacs/minimatch#29. We agreed at the standup today to eschew minimatch/globmatch and just do a simpler syntax of our own, supporting only /*/?. This will be easier to document and much faster (as noted above). I'll file a spinoff bug on changing the prefs system to use this new setup too, for consistency. |
|
|
|
|
|
|
|
Done with my initial review. |
|
|
|
|
|
Looks good. Merging. |
Thursday Feb 27, 2014 at 00:34 GMT
Originally opened as adobe/brackets#7015
Implements Find in Files exclusions user story, with basic unit tests.
autoClosebehavior, rather than its own one-off focus tracking logic.isLockedOpen()function that keeps the bar open regardless of focus changes. Needed for existing Find in Files functionality - bar stays open while search in progress.<body>) if they specify an "attached-to" attribute pointing back at the widget inside the bar. Needed for newly-added picker dropdown.peterflynn included the following code: https://github.com/adobe/brackets/pull/7015/commits
The text was updated successfully, but these errors were encountered: