Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Fixes #2608 (Quick Open shows red on first use) #3184

Merged
merged 5 commits into from
Apr 4, 2013

Conversation

dangoor
Copy link
Contributor

@dangoor dangoor commented Mar 20, 2013

Fixes #2608 (Quick Open shows red on first use) and also makes Quick Open more responsive on large projects by not immediately invalidating the cached file list.

Just eliminating the "red on first use" is a one line change:

        var isNoResults = (results.length === 0 && fileList && !this._isValidLineNumberQuery(this.$searchField.val()));

But I was also keen to make Quick Open more useful for Brackets again by updating the file list in the background, providing possibly mildly stale results in the meantime.

Ideally, we'd have a spinner while the loading is happening, but I have other things on my plate right now and didn't want to try to build a spinner into the modal bar right now.

…en more responsive on

large projects by not immediately invalidating the cached file list.
@ghost ghost assigned peterflynn Mar 22, 2013
Now that the file list in Quick Open is more lazily retrieved, we should
clear out the old StringMatcher caches to avoid possibly stale data
sticking around even after the file list has arrived.
@dangoor
Copy link
Contributor Author

dangoor commented Mar 27, 2013

The latest change refreshes the StringMatcher caching when the updated file list arrives.

I hope we can get this in soon, because Quick Open has become a lot less usable recently in Brackets and this helps a lot.

@@ -391,7 +391,7 @@ define(function (require, exports, module) {
*/
QuickNavigateDialog.prototype._handleResultsReady = function (e, results) {
// Give visual clue when there are no results
var isNoResults = (results.length === 0 && !this._isValidLineNumberQuery(this.$searchField.val()));
var isNoResults = (results.length === 0 && fileList && !this._isValidLineNumberQuery(this.$searchField.val()));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it needs to be ...&& (fileList || [search mode is not Quick Open]) &&...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which I guess would be (fileList || currentPlugin), since I think we can be guaranteed that _filterCallback() (which updates currentPlugin) runs before _handleResultsReady().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, yes, you're right.

@peterflynn
Copy link
Member

We should probably add a simple unit test for StringMatcher.reset().

I notice there's also a QuickOpen test suite but it only contains one testcase, related to scrolling... so it's probably not worth trying to add anything more to cover this new behavior.

I would like to spend some time testing by hand tomorrow before we merge this though... knowing that Quick Open timing has been a very delicate area in the past :-/

* Fixes the detection of no results
* removes extra call to matcher.reset()
* adds a test for StringMatcher.reset
@dangoor
Copy link
Contributor Author

dangoor commented Apr 3, 2013

I've added a test for StringMatcher.reset.

I've noticed that I'm now getting a popup saying that the indexer has reached the maximum number of files. We'll probably need a better solution to this soon. (Or, we can kick the can down the road by providing a way to exclude node_modules, which is now 74% of the total files in my brackets directory.)

@peterflynn
Copy link
Member

Unit test looks good. Will test a little bit tonight before merging.

I haven't hit the 10k file max yet on my machine... I guess I have less stuff in extensions/dev or something :-) But yeah, this patch is definitely just a stopgap. I hope we get file watchers soon... and exclusions wouldn't hurt too -- not just for Quick Open, but also Find in Files, etc.

@peterflynn
Copy link
Member

Hmm, in testing on my slowish Boot Camp machine I'm seeing some cases where a red background appears briefly.

For example: refresh Brackets; as soon as it's done, launch Quick Open and type something like "docman." You'll see a red background up until the list is available (i.e. until the initial file index build is complete).

I think this is because isNoResults is undefined, while jQuery.toggleClasss() in all its awesome jQueryism-ness requires a strict boolean instead of just truthy or falsy. If I change the code to toggleClass(..., !!isNoResults) then it seems to fix all these cases.

@@ -391,7 +391,7 @@ define(function (require, exports, module) {
*/
QuickNavigateDialog.prototype._handleResultsReady = function (e, results) {
// Give visual clue when there are no results
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, while you're making another commit... could you add something here to clarify what we mean by "no results"? E.g. "...when there are no results - unless we're in 'Go to Line' mode, where there are never results; or when we're in file search mode and still waiting for the index to get rebuilt."

@peterflynn
Copy link
Member

Actually, I'd suggest using Boolean(isNoResults) rather than !! -- looks like that's what our other code does, and it's a bit cleaner looking.

@peterflynn
Copy link
Member

Even with the boolean fix, I'm still seeing it turn red in some cases -- when I use Go to Definition, hit Escape, and then use plain Quick Open. It seems to come and go though, so it may be rare enough (especially on faster systems) to not worry about. It's definitely still an improvement over the current behavior on master.

@peterflynn
Copy link
Member

I think that remaining bug may be because of the case at the top of _filterCallback(), where it returns without updating currentPlugin. Still think it's probably not worth trying to fix right now though.

@dangoor
Copy link
Contributor Author

dangoor commented Apr 4, 2013

I discovered that my test didn't actually work (bitten by the long-standing caching issue – I didn't have the dev tools open). I just needed to move the this.addMatchers call into a beforeEach.

I added the boolean fix and updated the comment.

I wasn't able to reproduce the remaining "field turning red", and I agree with you that the new behavior is probably good enough for now.

@dangoor
Copy link
Contributor Author

dangoor commented Apr 4, 2013

Given the trivial nature of the updates I needed to make, I'll go ahead and merge.

dangoor added a commit that referenced this pull request Apr 4, 2013
Fixes #2608 (Quick Open shows red on first use)
@dangoor dangoor merged commit b4c1c48 into master Apr 4, 2013
@dangoor dangoor deleted the dangoor/2608-quickopen-red branch April 4, 2013 13:05
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Quick Open for files can briefly show red erroneously on first use
2 participants