directional (arrow) keys being interpreted improperly

[michaelficarra]

It seems <up> is now a synonym for u, <down> is now a synonym for d, and so on.

[michaelficarra]

I think I found the source of the issue: https://github.com/misfo/jim/blob/b55bd46a70425a8cffc8b7ee9da76175f15e184c/src/ace/module.coffee#L39-41

[misfo]

Yikes! The ace keybinding interface just changed and it sounds like we have some regressions. Time to improve the test coverage. Thanks for the report

On Aug 1, 2011, at 6:35 PM, michaelficarrareply@reply.github.com wrote:

It seems <up> is now a synonym for u, <down> is now a synonym for d, and so on.

Reply to this email directly or view it on GitHub:
#7

[misfo]

pushed this to gh-pages too. we've got some tests to prevent a regression like this again

[michaelficarra]

Huh. Now the arrow keys in visual mode are displaying the same visual mode quirks as before your ace update, but h, j, k, l in visual (and visual line) mode work properly.

[misfo]

I hate to give a works-for-me-there's-no-way-my-code's-wrong response, but are you sure you're not getting a cached version? Can you see the fixed line in lib/ace/module.js in your browser's web inspector?

Chrome's force-refresh makes me think I'm taking crazy pills. It will still render files from the local cache. Clearing the cache is the only way I've been able to force bypassing it's cache...

[michaelficarra]

Yeah, I made sure to clear the cache and compared the JS against the new version because that was my first suspicion as well.

[misfo]

I misread your comment. I'm getting the same behavior you described.

Ace's default keybindings for arrow keys clear the selection whenever you press them without the shift key. Jim has always passed arrow keypresses through to Ace, so this behavior must have been the same before this commit.

The arrow keys should be mapped to their hjkl counterparts. I'll create an issue