Numeric PAD is not usable anymore on MAC OS X #2654
Comments
|
What do you mean exactly? Please provide more information |
|
When i enter numeric key from my numeric pad or =+- keys in my shell, nothing happens. |
|
This is really weird. Please post the output of |
|
With command read, it's ok all numerical keys are functionnal. And my command bindkey |
|
Exactly the same problem. |
|
So must we consider it's an iTerm2 Bug ? And close this issue if so. |
|
I don't think, because this bug appears just after the last oh-my-zsh update. It worked perfectly before. |
|
Can you use |
|
I can try but i never user gît bisect. Just read doc., i'll try tomorrow. |
|
It's very simple actually. You mark a commit in which the issue appears ( You'll have to reload OMZ to test each commit, you can use the |
|
OK i will test it tomorrow, how exactly do you reload a specific commit of thé réponse ? |
|
Using Then, if you have the |
|
Ok, tried 'git bisect' for the first time... what a wonderful tool ! :-) Here is the result : |
|
I knew you'd like it Run |
|
Output for |
|
Well done Ricard, i'll try next time. Now i know much more about omzsh and a little more about git. |
|
I have a similar issue, also tracked down to the same commit with Those |
|
@simonwhitaker the issue you describe has been submitted in #1433, #2628 and #2632, and has a PR #2511 pending to test and merge; check those out. This issue is different. To @ricard33, you have nearly the same |
Those are issues with the |
|
My mistake, I read substring instead of beginning zmodload zsh/terminfo
bindkey "$terminfo[kcuu1]" history-beginning-search-backward-end
bindkey "$terminfo[kcud1]" history-beginning-search-forward-end |
|
I'm getting this issue as well in iTerm2, due to the same commit. I'm on OSX with the Mac extended keyboard. Anything else I can provide, let me know.. I use the numpad enter key a lot :) |
|
Ok, what we have so far:
My guess is that iTerm2 uses a different This is your homework:
If that doesn't cut it we'll have to talk with people over at iTerm2 |
Nope, I'm using Terminal.app
Nope, mine is
Here's my
Correct |
|
After doing a But |
|
Same here. Reverting ff0cafa removes said functions. |
|
@simonwhitaker I was refering to the others. Please note that this issue describes a malfunction using the numeric pad keys; if I understood correctly, the issue you reported was that up/down arrow keys didn't bring up a previous command with the same prefix. Even if the offending commit is the same, if you don't experience any trouble with the numerical pad you should really open a new issue. Also, have you tried my suggestion in #2654 (comment)? To the others, try autoloading the functions before step 3: autoload -U zle-line-init && zle-line-init
autoload -U zle-line-finish && zle-line-finishthen paste the output using Finally, it seems prezto had the same issue. |
|
|
Also, this is my oh-my-zsh after the revert: https://gist.github.com/quicksnap/9844880 |
|
Yeah don't even bother trying what I said. It seems terminfo is a PITA everywhere [1][2]. Report your zsh versions ( |
|
Same problem for me. zsh 5.0.5 (x86_64-apple-darwin13.0.0) |
|
Not sure that's a good solution. This would not fix the issue if you use a none-standard layout that sends the |
|
Thanks @tomduncalf !!!!!!! |
|
This is a cool solution: http://superuser.com/a/742193/1722 |
|
After upgrading to Yosemite I had to uncheck a specific setting in "Terminal" preferences: Terminal Preferrences, Advanced Tab, I unchecked the box in the 'Input' options section: "Allow VT100 application keypad mode" then the numpad keys worked https://discussions.apple.com/thread/6613968 |
|
Even better, @philfreo. Thanks! |
Preferences > Advanced Tab > unchecked "Allow VT100 application keypad mode." ohmyzsh/ohmyzsh#2654 (comment)
|
Honestly, having to set special settings in ones terminal can hardly be considered a fix. For me everything stays as broken as from the beginning, using urxvt. |
|
My guess is that an unchecked setting is what people have always run, but the upgrade to Yosemite changed the default setting of this. = |
|
Hi ! This post fix the problem ! |
|
The solution from @philfreo worked for me, thanks |
|
I am on the macintosh. As did Unchecking VT100 in advanced preferences Either of these are acceptable. In the interest of keeping the project unmodified. I am going with unchecking the VT100 preference. |
|
+1 for Unchecking VT100 in advanced preferences. Had the key mapping working for a bit but it caused strange issues in |
|
I was wondering why the Num Pad wasnt working and i ran into this issue. The problem still persists. |
|
@volure you saved my day. Thank you very much. I mapped the following keys in my |
|
We should probably add these bindings by default in OMZ if we are going to be using We may not have a great way of doing this portably, though. The However, I tried out a few terminal emulators, and there was some minor variation in the sequences they issued. And the terminfo entries on OS X don't have those capabilities defined; they may be missing elsewhere. So we couldn't use terminfo to do it portably. We could just hardcode it, and live with a couple keys not working right in some terminals, leaving it up to users to tweak it if they really wanted to. Or start including supplemental terminal info in OMZ to patch up those discrepancies. We might even want to rethink the whole Is there any interest in binding the numeric keypad keys to something besides numeric character entry? |
mcornella
added
the
Topic: bindkey
|
This should definitely be default |
|
Surprising that this issue is still open after 2 years. Any plans on fixing it in one of the next updates? What is the benefit of keeping the num pad not working? Or is this simply a bug that has not been looked at? Using a standard terminal on OSX El Capitan. UPD: The solution by @doomsbuster solved the issue. Not sure this hack is something every user should be doing. |
|
Yeah, I'm suprised. @kachkaev |
It's tied in to the At this point I'm thinking the solution is to ditch smkx/rmkx. |
|
17k forks and no one can patch this? |
|
With these bigger changes, it's not straightforward to patch for everyone (without a lot of testing). Until we have a nice PR to go along with this, am going to close this and suggest folks refer to suggested solution: |
|
I don't know if it's the case to open a new issue, but I'd just like to point out that I'm using a cheap laptop which seems to have the enter key mapped as the numpad enter key. It taken a lot of time to me, to figure it out, as I noticed the problem after doing a lot of changes to the machine (fresh linux install). Idk why the manufacturer did this, and I've fixed the problem with this Anyway I've tried the #2654 fix, numpad keys are not working, but that's fine, mine is not a Mac. The most annoying thing of this problem is that's impossible to confirm while reconfiguring the kernel with Yeah, I know, is not an operation that one does everyday. I wanted just to tell that there are pc manufacturers that are making weird keyboards out there, consider it :-) |
and others
Since last update of yesterday 24th March my numerical pad is not usable anymore in my shell.
All our team developers are in the same situation.
The text was updated successfully, but these errors were encountered: