RFE: Better quick open

[Al.]

This is feature request for quick open function. When project have many files it's pain to use quick open. I suggest improve filter a bit. May be make it works like in Command-T vim plugin (or go to file function in textmate). Something like typing 'acad' should find 'app/controllers/admin/dashboard_controller.rb'

[Al. (bug-odesk)]

Also will be good if you will be able to add 'default directory for quick open' option (or may be set it when scribes started as `scribes /path/to/project/dir/`)

[Mystilleef (mystilleef)]

How does Scribes know the project directory?

[Al. (bug-odesk)]

for example start scribes as i wrote before `scribes /path/to/project/root/`, also may be make 'open dir as project' button.

[Mystilleef (mystilleef)]

I don't like either solutions. I'm open to more ideas though. I want Scribes to automatically and intelligently figure out which folders to search without any input or configuration from the user.

[Al. (bug-odesk)]

find parent directory contains .git folder (or bzr, svn etc) for example? also check for any files that could be created by eclipse, idea, etc. and leave option for user to touch some file (lets say .scribes) and it will be root.

[Mystilleef (mystilleef)]

That sounds good.

[Al. (bug-odesk)]

What's about this fuzzy search? Is it good idea?

[Mystilleef (mystilleef)]

It already does fuzzy search.

[Al. (bug-odesk)]

Seems like not, at least in latest ppa build. For example i opened Gemfile in rails application root and then pressed ctrl+alt+o. If i write 'user' it will find app/models/user.rb, but if i write 'apu' it wont find anything (but should find app/models/user.rb, because 'ap' matches to app, and 'u' matches to user.rb)

[Mystilleef (mystilleef)]

That type of fuzzy searching leads to more matches. Which may be good or bad. The kind of fuzzy search scribes does allows you to filter more efficiently. For example if you want to open all the files in models, you just type models and the results will be very accurate. With the fuzzy searching you're recommending, when I type models, all kinds of irrelevant results show up. The advantage of your solution is that it allows you search on paths. It's a question of searching based on paths vs searching based on names. I prefer searching based on names because it's more natural.

[Al. (bug-odesk)]

Searching in paths + in names with relevance sorting (e.g. 'model' should show exact matches of file names first, then exact matches on paths, then rest results). It will allow to navigate in big projects way more faster. Just one thing will be needed is good caching. But as i know there is a lot good implementations of it in internet (don't know about python, but in ruby it's done in Command-T)

[Al. (bug-odesk)]

And searching based on names can give many results too. In big rails project there is really many files named 'user.rb' or user_something.rb' for example. it can be models, controllers, test, etc. But if fuzzy search that i suggest will be implemented it will be easy to find those files just typing 'spus' (for specs/models/user_spec.rb) for example. Anyway it can be implemented like optinion in preferences menu.

[Mystilleef (mystilleef)]

I'll implement it.

[Al. (bug-odesk)]

Thanks a lot. I understad that it will be faster if i could provide patch, but my python knowledges is really poor...

[Mystilleef (mystilleef)]

I'll upload a fix for fuzzy search in about 10 mins. Or if you want I can email you an updated plugin. Just email me. The other features will have to wait a little since I plan on rewriting quick open anyway.

[Al. (bug-odesk)]

I'm not in hurry. I'll wait.

[Javier Lorenzana (skqr)]

Hey!

Sorry, it just sounds to me that bUg. might not realize that in order to filter huge projects while searching for names you just need to type a partial *path*, as opposed to just a name.

"ls/user" would give you the user_spec.rb that he was looking for in the last example he posted.

IMHO, the type of fuzzy search he proposes makes absolutely no sense.

On the other hand - is anybody familiarized with Zsh's globbing?

"s/m/u" expands to "specs/models/user_spec.rb" as would "sp*/**/user*".

Having control over what results you get is essential to Quick Open being both usable and fast.

I've been working with Scribes on huge projects for the past three years, and I've never found Quick Open to fall short on me.

Anyway, cheers.

[Al. (bug-odesk)]

zhs globbing is good too, but what i suggest allows to type less and get required file. check 'live demonstration' screencast on https://wincent.com/products/command-t to see how it should work.

[Mystilleef (mystilleef)]

That link is broken. I'm playing with a rather primitive implementation of fuzzy search on Scribes and I have to say it's very expensive and slow on large projects. I'm doing a search on the top level directory of the Scribes folder (50K lines of code). If I can't work out the peformance issues, I'm going to stick with solution I have now.

[Al. (bug-odesk)]

Strange, link works well for me. Anyway preformance issues can be fixed i think. you can check how it works in command-t by goind to http://www.vim.org/scripts/script.php?script_id=3025 and download command-t-0.8.1.vba. it's written in ruby.

[Javier Lorenzana (skqr)]

OK, bUg., but, how much less, and at what cost?

There is such a thing as "too magical". If a feature takes control away from me, performing a lot of stuff I never asked for, just because it's *guessing* that's what I want, well, I can't say I'd be happy about that.

Truth is, it's all about cost-benefit. Sure, you get to type two characters less to find a particularly tricky file to find. The other 95% of the times, when you are looking for "regular-finding-difficulty" files, you get a bucket load of false hits and a ton of bricks in performance sluggishness.

Worth it? Don't think so.

What I have to say about Zsh's globbing is that it doesn't take control away from you. If you want it to do it's magic, you just add a *, or you type partial beginnings of each directory/file in the path.

I have to say, I've used a lot of quick open implementations, and so far Scribe's is on the lead.

The only two things I've ever felt might be missing are:
a) A "filter" configuration - just a string, e.g.; ".svn/*;*~;*.tmp"
b) Support for standard wildcards; ? for a single char, * for 0 or more.

[Al. (bug-odesk)]

If it really hard to implement on python such thing (which implemented using ruby and works fast) then zsh way better. But imho all depends on good caching. Yea it will require a bit more RAM, but as i know it's not a problem anymore (since almost everyone have more than 1gb ram).

[Mystilleef (mystilleef)]

It brings up a lot of false positives as I had anticipated. But when it's ranked it's not too bad. However it falls apart when you have long paths and file names. It's good for paths and file names that are short. If you have folders containing thousands of files, it's useless. If you have smaller folders it can be of benefit. My verdict is that I don't like it. It's an overrated feature. BUT, I'll put up a zip of the plugin tomorrow that has this feature for people who want it. I'm not sure its going to be in Scribes.

I'll implement ZSH-like or BASH-like re when I do the rewrite for 0.5. I'll also have all editors share the same search data. Finally, we'll also have the project searching as discussed above. All that will be the first other of business for 0.5.

I'll put up a link to the plugin tomorrow so you can test it bUg. I'll also try to use it for another week or so to see if I change my mind about it.