Case insensitive ranking for dirspec

[fabiopelosin]

I think that autojump would be better if it would have a case insensitive ranking. I find shift to be an expensive key for a tool that I use so often.

$ ajutojump --stat | grep -i myapp
0.8:    /Users/banana/.myapp
262.2:  /Users/banana/super/nested/path/MyApp

$ j my__
my__1__/Users/banana/.myapp    my__2__/Users/banana/super/nested/path/MyApp

This behavior confused me as I want to just to type $ j my to cd /Users/banana/super/nested/path/MyApp.

[joelthelion]

Hi Fabio,

If you find shift so expensive, why do you use capitals in your app's name (honnest question!)?

I understand why you'd want this change, but unless there is overwhelming support for this, I'd rather leave it the way it is, because I think it makes sense to distinguish capitals from lowercase letters if the filesystem does.

Note that as a work around, you can use any part of the name of the directory as a dirspec, so j pp would probably work. You can also change the behavior of autojump by patching it, it should be pretty straight forward (and I can help you if you're stuck).

[fabiopelosin]

Hi Joel,

First of all, thanks for autojump. I love it.

If you find shift so expensive, why do you use capitals in your app's name (honnest question!)?

I just tend to give proper capitalization to my folder names. I don't think that this is uncommon. For example, I'm on a Mac with the default filesystem (which is case insensitive but case preserving) and many system folders are capitalized by default. It also happens when I clone a git repo.

Nonetheless in terminal or in quicksilver i don't think about case. Also note how this is the case in this comment on #53 where lowercase strings are used to match capitalized titles.

I understand why you'd want this change, but unless there is overwhelming support for this, I'd rather leave it the way it is, because I think it makes sense to distinguish capitals from lowercase letters if the filesystem does.

Imo, even if the file system is case sensitive, there should be few to none cases where the user would want to distinguish a folder on autojump by case. I guess that people, usually, give different names to different folders and even if two folder are distinguished by name the ranking should sort things out (note however, that I never used a case sensitive file system). Also this is the standard behavior of Quicksilver.

Note that as a work around, you can use any part of the name of the directory as a dirspec, so j pp would probably work.

Thanks I wasn't aware of that.

You can also change the behavior of autojump by patching it, it should be pretty straight forward (and I can help you if you're stuck).

I prefer to stick with the default version for being able update without need to re-patch every time.

Now I'm a bit busy but if you changed your mind I can patch it in future. Otherwise please go ahead and close the issue.

[joelthelion]

@wting : I'll love your input on that question!

[wting]

I don't think there should be a reason we can't support this, but as with this and fuzzy/flex matching people are going to start having separate opinions as to preferred behavior.

I think we should start implementing a way to modify autojump's behavior, either through the use of an ~/.autojumprc or environmental variables.

[shelhamer]

Just chiming in since I'm working on the fuzzy/flex matching: since autojump is already case-insensitive when a case exact match is not found, I'm not sure what the desired ordering would be. Uppercase before lowercase, in descending number of upper case letter matches?

I second the case for environment variable configuration. I was using command line switches as a temporary development fix, but it is awkward and I doubt we want people hacking the definition of the j alias in order to get their desired behavior.

This raises the broader issue of ranking matches given both scores and match quality. The approx matching thread might be the place for this discussion. I'm mulling over whether or not it would ever be desirable to rank an approximate match with high scores over an exact match with almost zero score. This might be another matter of taste that could be configurable?

[wting]

@irrationalfab : Pull the latest commit and set the environmental variable export AUTOJUMP_IGNORE_CASE=1. autojump will ignore case and return the highest matching path.

[fabiopelosin]

Sweet, thanks!

Unfortunately I'm not able to get it to work correctly.

$ autojump --version
autojump release-v20-4
$ echo $AUTOJUMP_IGNORE_CASE
1
$ autojump --stat
10.0:   /Users/fabio/Documents
14.1:   /Users/fabio/Documents/GitHub/feeds.cocoapods.org
14.1:   /Users/fabio/.local/share/autojump
17.3:   /Users/fabio/Documents/GitHub/CocoaPods
30.0:   /Users/fabio/Documents/GitHub
Total key weight: 85. Number of stored dirs: 5
$ j coco
/Users/fabio/Documents/GitHub/feeds.cocoapods.org

---

Unrelated: also I had some trouble with autojump not creating the autojump.txt file and therefore not keeping track of the directories. After touching the file manually everything worked as expected.

Not, sure if it was a permission issue, but I would exclude it because I was removing autojump directories before install. I was using the homebrew version, but installed it and cleaned the dirs and installed back again.

[wting]

It was a quick fix and I've bumped it to v20-5. Reinstall and let me know how it goes.

╭─ting@noa ~/Cocoa ‹python-2.7.3› ‹ruby-1.9.3› 
╰─➤  echo $AUTOJUMP_IGNORE_CASE
1
╭─ting@noa ~ ‹python-2.7.3› ‹ruby-1.9.3› 
╰─➤  js | grep cocoa
21.9:   /home/ting/feeds.cocoapods.org
61.3:   /home/ting/Cocoa
╭─ting@noa ~ ‹python-2.7.3› ‹ruby-1.9.3› 
╰─➤  j coco
/home/ting/Cocoa
╭─ting@noa ~/Cocoa ‹python-2.7.3› ‹ruby-1.9.3› 
╰─➤

[fabiopelosin]

Awesome! It works perfectly, thanks.

Interesting shell btw.