search

ProLoser / Github-Omnibox

Github Commands from Google Chrome Omnibox (address bar)
http://goo.gl/n5HJw
MIT License
386 stars 24 forks source link

Can you let the app make suggestion on user browsering history? #48

Closed octref closed 9 years ago

octref commented 9 years ago

A lot of times, I only remember the repo name, or only a word in the repo name. But I'm sure I've visited its github page. So if I have visited a project at someone/my-cool-project, can you make the app suggest it when I only enter gh my-cool, or gh cool? Currently it doesn't show anything.

ProLoser commented 9 years ago

Currently I don't track your browsing history. What you're describing could be done but would require a big body of work to add tracking and storing of all the github repos you've opened and is essentially the equivalent to bookmarking or starring a repo. If you have ever starred a repo you can get suggestions by doing gh *cool

octref commented 9 years ago

That does make sense. But I'm using a lot of Node, and sometimes I want to look into small packages' implementations and don't have them starred, such as body-parser, vinyl-buffer. Does it make sense to utilize chrome.history API for keyword-based search? For example, with gh keyword, you use chrome.history.search to retrieve all URLs, filter out non-Github ones, and provide a list of suggestions (ranked by your own repo > starred repo > non-starred repo)?

ProLoser commented 9 years ago

That's an interesting idea I did not think about @octref

ProLoser commented 9 years ago

@rodyhaddad Hey man don't know if you're still around anymore, but would like your input on how to do this ^. For some reason some of the behavior that used to occur seems to have regressed a little. For instance, if i do /whatever and there are no suggestions, it should take me to ProLoser/whatever but it takes me to search results instead.

ProLoser commented 9 years ago

@octref Although it's not the best solution, and I can't speak to how well it will worked, I added a simplistic implementation of what you asked:

gh ~vinyl should work. You must prefix it with ~.

Right now, it doesn't refer to your starred or owned repos and yes it requires a prefix. I actually like the idea of dropping the prefixes and just merging all of these together as you suggested into the base search (unprefixed) however this will require a little bit of futzing and relearning of how the code works since @rodyhaddad did a massive amount of work around it but unfortunately we failed to document most of it lol.

ProLoser commented 9 years ago

@octref So I continued messing with the code and created an atomic-searching branch of this repo. You can load it up and try it out yourself, but it probably buggy and unreliable.

octref commented 9 years ago

@ProLoser Umm, I tried ~vinyl today, but unfortunately it doesn't work.

I have some experience writing Chrome extensions, and built one for this purpose this afternoon: https://github.com/octref/goto-github-repo It's under MIT license. If you see anything you can use, go ahead take it.

It can't search for multiple keywords, or update stored repos in repoMap when I visit a new repo page. I'll do these two features tomorrow.

But now I'm quite happy using it. I don't need a lot of features. Just when I enter a keyword, it shows repos I visited, and goto the github page when I press enter.

I took a rough look at atomic-searching. Instead of using regex, you can use https://gist.github.com/jlong/2428561 which handles URL nicely.

ProLoser commented 9 years ago

You're aware I was talking about another branch, right? Not the officially published plugin.

octref commented 9 years ago

I saw an update for the extension this morning asking permission for history, so I thought you published it. The branch version is creating a dialog for auth each time I type a character.

OK, I get it to work. But the search is a bit slow.

ProLoser commented 9 years ago

I'm aware it's slow and not really good. There are some complexities. For instance, your plugin performs a pre-emptive caching upon initialization, which results in faster searching. However, if your 100 most recent history items are different sub-pages of a repo or just not repos at all, lets say it may result in only 5-10 distinct repos, then your search results will be very limited. There's also the issue that as you type in characters, you would be better suited to get more accurate results.

It currently performs a search with every keypress, which granted is not super fast. Optimizations could be made around caching distinct results, etc, but I was just trying to get something that works in a short amount of time.

ProLoser commented 9 years ago

If you feel like hacking on it, the relevant lines of code are here: https://github.com/ProLoser/Github-Omnibox/blob/999ec4b2437acd4791fbbbc85c3bbfde7b9634ab/src/patterns/repoActions.js#L335-L359

octref commented 9 years ago

I'm actually retrieving all histories (around ~35000), and building a hashmap with "owner/repo" as the key for all github.com pages. This hashmap is stored in chrome.storage.local and updated(now it doesn't update, but I'll implement it) as users visit new github.com pages.

I realize your extension is more powerful and complete, but I'm content with the one I have now. I hope my naive implementation can serve as a starting point for you to integrate this feature into Github-Omnibox.

Thanks!