{"action":"created","issue":{"url":"https://api.github.com/repos/substantial/atomfiles/issues/43","labels_url":"https://api.github.com/repos/substantial/atomfiles/issues/43/labels{/name}","comments_url":"https://api.github.com/repos/substantial/atomfiles/issues/43/comments","events_url":"https://api.github.com/repos/substantial/atomfiles/issues/43/events","html_url":"https://github.com/substantial/atomfiles/issues/43","id":95520765,"number":43,"title":"fuzzy file matching is too fuzzy","user":{"login":"nocash","id":78855,"avatar_url":"https://avatars.githubusercontent.com/u/78855?v=3","gravatar_id":"","url":"https://api.github.com/users/nocash","html_url":"https://github.com/nocash","followers_url":"https://api.github.com/users/nocash/followers","following_url":"https://api.github.com/users/nocash/following{/other_user}","gists_url":"https://api.github.com/users/nocash/gists{/gist_id}","starred_url":"https://api.github.com/users/nocash/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nocash/subscriptions","organizations_url":"https://api.github.com/users/nocash/orgs","repos_url":"https://api.github.com/users/nocash/repos","events_url":"https://api.github.com/users/nocash/events{/privacy}","received_events_url":"https://api.github.com/users/nocash/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-07-16T20:29:49Z","updated_at":"2015-07-19T14:13:20Z","closed_at":null,"body":"![teaching-channel - atom 2015-07-16 13-21-02](https://cloud.githubusercontent.com/assets/78855/8734364/6aa519f6-2bbe-11e5-8dc7-422b41be9d1c.png)\r\n\r\nLooks like improvements are currently under development in atom/fuzzaldrin#22"},"comment":{"url":"https://api.github.com/repos/substantial/atomfiles/issues/comments/122664198","html_url":"https://github.com/substantial/atomfiles/issues/43#issuecomment-122664198","issue_url":"https://api.github.com/repos/substantial/atomfiles/issues/43","id":122664198,"user":{"login":"jeancroy","id":12763666,"avatar_url":"https://avatars.githubusercontent.com/u/12763666?v=3","gravatar_id":"","url":"https://api.github.com/users/jeancroy","html_url":"https://github.com/jeancroy","followers_url":"https://api.github.com/users/jeancroy/followers","following_url":"https://api.github.com/users/jeancroy/following{/other_user}","gists_url":"https://api.github.com/users/jeancroy/gists{/gist_id}","starred_url":"https://api.github.com/users/jeancroy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jeancroy/subscriptions","organizations_url":"https://api.github.com/users/jeancroy/orgs","repos_url":"https://api.github.com/users/jeancroy/repos","events_url":"https://api.github.com/users/jeancroy/events{/privacy}","received_events_url":"https://api.github.com/users/jeancroy/received_events","type":"User","site_admin":false},"created_at":"2015-07-19T14:13:19Z","updated_at":"2015-07-19T14:13:19Z","body":"Because you where kind enough to share idea, I'll develop a bit more.\r\n\r\nSee that use case ?\r\nhttps://github.com/atom/fuzzy-finder/issues/57 (A)\r\nSomehow `ImportanceTableCtrl` should be prefered to `switch.css` when searching for `itc`\r\nSo that put some limit to the size-related penalty. \r\n\r\nAnother one:\r\nhttps://github.com/atom/fuzzaldrin/issues/17 (B)\r\n`diagonals` should be prefered to `Diagonal` when searching for `diag`\r\nHere a single character case 'D' vs 'd', should win, even if there one extra `s` at the end of the word.\r\n\r\nThose expectations kind of puts haystack size at the role of tiebreaker.\r\nWhy would we want to penalize large string ? Because the sheer size of them allow to do accidental matches. However when they do so, it tend to be isolated character, in the middle of nowhere, and that's what we are going to detect ! We can do so by counting the number of consecutive match (grouped character) and giving large bonus for that.\r\n\r\n However in this case \"**mode**rator\" is almost \"**mode**l\". Also my script would have attached the \"**u**\" to \"**u**ser\" instead of \"col**u**mns\". Final both match landmark character (word boundary) at \"**m**\" and \"**u**\". So I cannot guarantee that large string will be scored like garbage (because it's not garbage) and a tie breaker is exactly what you need.\r\n\r\n\r\nAnother interesting fact is that I find consecutive character very intuitive and use it to resolve otherwise contradictory cases. How do i know the lowercase \"**i**\" of \"**i**tc\" should prefer uppercase \"**I**\" of \"**I**mportance\" while lowercase \"**d**\" of \"**d**iag\" should reject uppercase \"**D**\" of \"**D**iagonal\" in favor of \"**d**iagonal\" ? Well \"diag\" score consecutive point in the actual word, while \"itc\" score consecutive in the acronym of the word ! Where the consecutive are, control the affinity for exact case vs acronym camelCase. It also ensure that if a large string accidentally match a landmark, not part of a sequence requested by query, we still get garbage like score.\r\n\r\n \r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n \r\n\r\n"}}