New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Numeric PAD is not usable anymore on MAC OS X #2654

Open
remy-theroux opened this Issue Mar 25, 2014 · 74 comments

Comments

Projects
None yet
@remy-theroux

remy-theroux commented Mar 25, 2014

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.

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 25, 2014

Collaborator

What do you mean exactly? Please provide more information

Collaborator

mcornella commented Mar 25, 2014

What do you mean exactly? Please provide more information

@remy-theroux

This comment has been minimized.

Show comment
Hide comment
@remy-theroux

remy-theroux Mar 25, 2014

When i enter numeric key from my numeric pad or =+- keys in my shell, nothing happens.
This only happens in zsh, other software is working as expected.
This happens since last update on the 24th March.

remy-theroux commented Mar 25, 2014

When i enter numeric key from my numeric pad or =+- keys in my shell, nothing happens.
This only happens in zsh, other software is working as expected.
This happens since last update on the 24th March.

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 25, 2014

Collaborator

This is really weird. Please post the output of bindkey. Also, if you run read, do they work (i.e. is anything output)?

Collaborator

mcornella commented Mar 25, 2014

This is really weird. Please post the output of bindkey. Also, if you run read, do they work (i.e. is anything output)?

@remy-theroux

This comment has been minimized.

Show comment
Hide comment
@remy-theroux

remy-theroux Mar 25, 2014

With command read, it's ok all numerical keys are functionnal.

And my command bindkey

"^@" set-mark-command
"^A" beginning-of-line
"^B" backward-char
"^D" delete-char-or-list
"^E" end-of-line
"^F" forward-char
"^G" send-break
"^H" backward-delete-char
"^I" expand-or-complete
"^J" accept-line
"^K" kill-line
"^L" clear-screen
"^M" accept-line
"^N" down-line-or-history
"^O" accept-line-and-down-history
"^P" up-line-or-history
"^Q" push-line
"^R" history-incremental-search-backward
"^S" history-incremental-search-forward
"^T" transpose-chars
"^U" kill-whole-line
"^V" quoted-insert
"^W" backward-kill-word
"^X^B" vi-match-bracket
"^X^E" edit-command-line
"^X^F" vi-find-next-char
"^X^J" vi-join
"^X^K" kill-buffer
"^X^N" infer-next-history
"^X^O" overwrite-mode
"^X^R" _read_comp
"^X^U" undo
"^X^V" vi-cmd-mode
"^X^X" exchange-point-and-mark
"^X*" expand-word
"^X=" what-cursor-position
"^X?" _complete_debug
"^XC" _correct_filename
"^XG" list-expand
"^Xa" _expand_alias
"^Xc" _correct_word
"^Xd" _list_expansions
"^Xe" _expand_word
"^Xg" list-expand
"^Xh" _complete_help
"^Xm" _most_recent_file
"^Xn" _next_tags
"^Xr" history-incremental-search-backward
"^Xs" history-incremental-search-forward
"^Xt" _complete_tag
"^Xu" undo
"^X~" _bash_list-choices
"^Y" yank
"^[^D" list-choices
"^[^G" send-break
"^[^H" backward-kill-word
"^[^I" self-insert-unmeta
"^[^J" self-insert-unmeta
"^[^L" clear-screen
"^[^M" self-insert-unmeta
"^[^_" copy-prev-word
"^[ " expand-history
"^[!" expand-history
"^[\"" quote-region
"^[\$" spell-word
"^['" quote-line
"^[," _history-complete-newer
"^[-" neg-argument
"^[." insert-last-word
"^[/" _history-complete-older
"^[0" digit-argument
"^[1" digit-argument
"^[2" digit-argument
"^[3" digit-argument
"^[4" digit-argument
"^[5" digit-argument
"^[6" digit-argument
"^[7" digit-argument
"^[8" digit-argument
"^[9" digit-argument
"^[<" beginning-of-buffer-or-history
"^[>" end-of-buffer-or-history
"^[?" which-command
"^[A" accept-and-hold
"^[B" backward-word
"^[C" capitalize-word
"^[D" kill-word
"^[F" forward-word
"^[G" get-line
"^[H" run-help
"^[L" down-case-word
"^[N" history-search-forward
"^[OA" up-line-or-search
"^[OB" down-line-or-search
"^[OC" forward-char
"^[OD" backward-char
"^[OF" end-of-line
"^[OH" beginning-of-line
"^[P" history-search-backward
"^[Q" push-line
"^[S" spell-word
"^[T" transpose-words
"^[U" up-case-word
"^[W" copy-region-as-kill
"^[[1;5C" forward-word
"^[[1;5D" backward-word
"^[[3~" delete-char
"^[[5~" up-line-or-history
"^[[6~" down-line-or-history
"^[[A" up-line-or-history
"^[[B" down-line-or-history
"^[[C" forward-char
"^[[D" backward-char
"^[_" insert-last-word
"^[a" accept-and-hold
"^[b" backward-word
"^[c" capitalize-word
"^[d" kill-word
"^[f" forward-word
"^[g" get-line
"^[h" run-help
"^[l" "ls^J"
"^[m" copy-prev-shell-word
"^[n" history-search-forward
"^[p" history-search-backward
"^[q" push-line
"^[s" spell-word
"^[t" transpose-words
"^[u" up-case-word
"^[w" kill-region
"^[x" execute-named-cmd
"^[y" yank-pop
"^[z" execute-last-named-cmd
"^[|" vi-goto-column
"^[~" _bash_complete-word
"^[^?" backward-kill-word
"^_" undo
" " magic-space
"!"-"~" self-insert
"^?" backward-delete-char
"\M-^@"-"\M-^?" self-insert

remy-theroux commented Mar 25, 2014

With command read, it's ok all numerical keys are functionnal.

And my command bindkey

"^@" set-mark-command
"^A" beginning-of-line
"^B" backward-char
"^D" delete-char-or-list
"^E" end-of-line
"^F" forward-char
"^G" send-break
"^H" backward-delete-char
"^I" expand-or-complete
"^J" accept-line
"^K" kill-line
"^L" clear-screen
"^M" accept-line
"^N" down-line-or-history
"^O" accept-line-and-down-history
"^P" up-line-or-history
"^Q" push-line
"^R" history-incremental-search-backward
"^S" history-incremental-search-forward
"^T" transpose-chars
"^U" kill-whole-line
"^V" quoted-insert
"^W" backward-kill-word
"^X^B" vi-match-bracket
"^X^E" edit-command-line
"^X^F" vi-find-next-char
"^X^J" vi-join
"^X^K" kill-buffer
"^X^N" infer-next-history
"^X^O" overwrite-mode
"^X^R" _read_comp
"^X^U" undo
"^X^V" vi-cmd-mode
"^X^X" exchange-point-and-mark
"^X*" expand-word
"^X=" what-cursor-position
"^X?" _complete_debug
"^XC" _correct_filename
"^XG" list-expand
"^Xa" _expand_alias
"^Xc" _correct_word
"^Xd" _list_expansions
"^Xe" _expand_word
"^Xg" list-expand
"^Xh" _complete_help
"^Xm" _most_recent_file
"^Xn" _next_tags
"^Xr" history-incremental-search-backward
"^Xs" history-incremental-search-forward
"^Xt" _complete_tag
"^Xu" undo
"^X~" _bash_list-choices
"^Y" yank
"^[^D" list-choices
"^[^G" send-break
"^[^H" backward-kill-word
"^[^I" self-insert-unmeta
"^[^J" self-insert-unmeta
"^[^L" clear-screen
"^[^M" self-insert-unmeta
"^[^_" copy-prev-word
"^[ " expand-history
"^[!" expand-history
"^[\"" quote-region
"^[\$" spell-word
"^['" quote-line
"^[," _history-complete-newer
"^[-" neg-argument
"^[." insert-last-word
"^[/" _history-complete-older
"^[0" digit-argument
"^[1" digit-argument
"^[2" digit-argument
"^[3" digit-argument
"^[4" digit-argument
"^[5" digit-argument
"^[6" digit-argument
"^[7" digit-argument
"^[8" digit-argument
"^[9" digit-argument
"^[<" beginning-of-buffer-or-history
"^[>" end-of-buffer-or-history
"^[?" which-command
"^[A" accept-and-hold
"^[B" backward-word
"^[C" capitalize-word
"^[D" kill-word
"^[F" forward-word
"^[G" get-line
"^[H" run-help
"^[L" down-case-word
"^[N" history-search-forward
"^[OA" up-line-or-search
"^[OB" down-line-or-search
"^[OC" forward-char
"^[OD" backward-char
"^[OF" end-of-line
"^[OH" beginning-of-line
"^[P" history-search-backward
"^[Q" push-line
"^[S" spell-word
"^[T" transpose-words
"^[U" up-case-word
"^[W" copy-region-as-kill
"^[[1;5C" forward-word
"^[[1;5D" backward-word
"^[[3~" delete-char
"^[[5~" up-line-or-history
"^[[6~" down-line-or-history
"^[[A" up-line-or-history
"^[[B" down-line-or-history
"^[[C" forward-char
"^[[D" backward-char
"^[_" insert-last-word
"^[a" accept-and-hold
"^[b" backward-word
"^[c" capitalize-word
"^[d" kill-word
"^[f" forward-word
"^[g" get-line
"^[h" run-help
"^[l" "ls^J"
"^[m" copy-prev-shell-word
"^[n" history-search-forward
"^[p" history-search-backward
"^[q" push-line
"^[s" spell-word
"^[t" transpose-words
"^[u" up-case-word
"^[w" kill-region
"^[x" execute-named-cmd
"^[y" yank-pop
"^[z" execute-last-named-cmd
"^[|" vi-goto-column
"^[~" _bash_complete-word
"^[^?" backward-kill-word
"^_" undo
" " magic-space
"!"-"~" self-insert
"^?" backward-delete-char
"\M-^@"-"\M-^?" self-insert
@ricard33

This comment has been minimized.

Show comment
Hide comment
@ricard33

ricard33 Mar 25, 2014

Exactly the same problem.
But it only occurs with oh-my-zsh into iTerm2.
With the default OSX Terminal, the numeric PAD is working.

ricard33 commented Mar 25, 2014

Exactly the same problem.
But it only occurs with oh-my-zsh into iTerm2.
With the default OSX Terminal, the numeric PAD is working.

@remy-theroux

This comment has been minimized.

Show comment
Hide comment
@remy-theroux

remy-theroux Mar 25, 2014

So must we consider it's an iTerm2 Bug ? And close this issue if so.

remy-theroux commented Mar 25, 2014

So must we consider it's an iTerm2 Bug ? And close this issue if so.

@ricard33

This comment has been minimized.

Show comment
Hide comment
@ricard33

ricard33 Mar 25, 2014

I don't think, because this bug appears just after the last oh-my-zsh update. It worked perfectly before.

ricard33 commented Mar 25, 2014

I don't think, because this bug appears just after the last oh-my-zsh update. It worked perfectly before.

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 25, 2014

Collaborator

Can you use git bisect to track down the offending commit?

Collaborator

mcornella commented Mar 25, 2014

Can you use git bisect to track down the offending commit?

@remy-theroux

This comment has been minimized.

Show comment
Hide comment
@remy-theroux

remy-theroux Mar 25, 2014

I can try but i never user gît bisect. Just read doc., i'll try tomorrow.

remy-theroux commented Mar 25, 2014

I can try but i never user gît bisect. Just read doc., i'll try tomorrow.

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 25, 2014

Collaborator

It's very simple actually. You mark a commit in which the issue appears (git bisect bad) and then another in which the issue doesn't (git bisect good), then git will select commits between those two and you have to mark it as good or bad until you found the offending commit.

You'll have to reload OMZ to test each commit, you can use the src() function in the zsh_reload plugin to speed things up (you'll have to copy it to your .zshrc, if you load it using the plugins variable it won't be able to find it since you'll be switching between commits).

Collaborator

mcornella commented Mar 25, 2014

It's very simple actually. You mark a commit in which the issue appears (git bisect bad) and then another in which the issue doesn't (git bisect good), then git will select commits between those two and you have to mark it as good or bad until you found the offending commit.

You'll have to reload OMZ to test each commit, you can use the src() function in the zsh_reload plugin to speed things up (you'll have to copy it to your .zshrc, if you load it using the plugins variable it won't be able to find it since you'll be switching between commits).

@remy-theroux

This comment has been minimized.

Show comment
Hide comment
@remy-theroux

remy-theroux Mar 25, 2014

OK i will test it tomorrow, how exactly do you reload a specific commit of thé réponse ?

remy-theroux commented Mar 25, 2014

OK i will test it tomorrow, how exactly do you reload a specific commit of thé réponse ?

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 25, 2014

Collaborator

Using git checkout and the hash of the commit. For example, if you wanted to test oh-my-zsh in the commit b9841b0 (from 2 weeks ago) you would run git checkout b9841b0 (you only need to specify the first few characters).

Then, if you have the zsh_reload plugin enabled, you just run src and test if the numpad keys work. If you don't have zsh_reload you'll need to restart the terminal to reload oh-my-zsh, then do the test. Once you've marked one bad commit and one good, git will do the job for you, you just follow the instructions. Good luck!

Collaborator

mcornella commented Mar 25, 2014

Using git checkout and the hash of the commit. For example, if you wanted to test oh-my-zsh in the commit b9841b0 (from 2 weeks ago) you would run git checkout b9841b0 (you only need to specify the first few characters).

Then, if you have the zsh_reload plugin enabled, you just run src and test if the numpad keys work. If you don't have zsh_reload you'll need to restart the terminal to reload oh-my-zsh, then do the test. Once you've marked one bad commit and one good, git will do the job for you, you just follow the instructions. Good luck!

@ricard33

This comment has been minimized.

Show comment
Hide comment
@ricard33

ricard33 Mar 25, 2014

Ok, tried 'git bisect' for the first time... what a wonderful tool ! :-)

Here is the result :

ff0cafa14db5b728f823ee486ec1bf5a9d2725eb is the first bad commit
commit ff0cafa14db5b728f823ee486ec1bf5a9d2725eb
Author: Felix Dreissig <f30@f30.me>
Date:   Sun Oct 14 00:07:47 2012 +0200

    Make sure the terminal is always in application mode when zle is active.

:040000 040000 49f03635a9aa77b31993ddcec0e8b867dc8e8586 a7b0f05dbf1ecd80b936f0d928c8b92f761a66fc M  lib

ricard33 commented Mar 25, 2014

Ok, tried 'git bisect' for the first time... what a wonderful tool ! :-)

Here is the result :

ff0cafa14db5b728f823ee486ec1bf5a9d2725eb is the first bad commit
commit ff0cafa14db5b728f823ee486ec1bf5a9d2725eb
Author: Felix Dreissig <f30@f30.me>
Date:   Sun Oct 14 00:07:47 2012 +0200

    Make sure the terminal is always in application mode when zle is active.

:040000 040000 49f03635a9aa77b31993ddcec0e8b867dc8e8586 a7b0f05dbf1ecd80b936f0d928c8b92f761a66fc M  lib
@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 25, 2014

Collaborator

I knew you'd like it 😄

Run infocmp and paste the output please
/offending PR: #1355

Collaborator

mcornella commented Mar 25, 2014

I knew you'd like it 😄

Run infocmp and paste the output please
/offending PR: #1355

@ricard33

This comment has been minimized.

Show comment
Hide comment
@ricard33

ricard33 Mar 25, 2014

Output for infocmp :

#   Reconstructed via infocmp from file: /opt/local/share/terminfo/78/xterm
xterm|xterm terminal emulator (X Window System),
    am, bce, km, mc5i, mir, msgr, npc, xenl,
    colors#8, cols#80, it#8, lines#24, pairs#64,
    acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
    bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
    clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M,
    csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
    cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
    cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
    cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
    dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K,
    flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG,
    ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L,
    ind=^J, indn=\E[%p1%dS, invis=\E[8m,
    is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F,
    kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~,
    kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^H, kcbt=\E[Z,
    kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
    kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
    kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
    kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
    kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
    kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
    kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
    kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
    kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
    kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
    kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
    kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
    kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
    kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
    kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
    kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
    kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
    kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
    kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
    kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
    kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
    memu=\Em, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM,
    rin=\E[%p1%dT, rmacs=\E(B, rmam=\E[?7l, rmcup=\E[?1049l,
    rmir=\E[4l, rmkx=\E[?1l\E>, rmm=\E[?1034l, rmso=\E[27m,
    rmul=\E[24m, rs1=\Ec, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
    setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
    setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
    setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
    sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
    sgr0=\E(B\E[m, smacs=\E(0, smam=\E[?7h, smcup=\E[?1049h,
    smir=\E[4h, smkx=\E[?1h\E=, smm=\E[?1034h, smso=\E[7m,
    smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
    u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,

ricard33 commented Mar 25, 2014

Output for infocmp :

#   Reconstructed via infocmp from file: /opt/local/share/terminfo/78/xterm
xterm|xterm terminal emulator (X Window System),
    am, bce, km, mc5i, mir, msgr, npc, xenl,
    colors#8, cols#80, it#8, lines#24, pairs#64,
    acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
    bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
    clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M,
    csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
    cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
    cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
    cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
    dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K,
    flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG,
    ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L,
    ind=^J, indn=\E[%p1%dS, invis=\E[8m,
    is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F,
    kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~,
    kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^H, kcbt=\E[Z,
    kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
    kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
    kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
    kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
    kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
    kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
    kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
    kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
    kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
    kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
    kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
    kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
    kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
    kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
    kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
    kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
    kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
    kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
    kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
    kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
    kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
    memu=\Em, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM,
    rin=\E[%p1%dT, rmacs=\E(B, rmam=\E[?7l, rmcup=\E[?1049l,
    rmir=\E[4l, rmkx=\E[?1l\E>, rmm=\E[?1034l, rmso=\E[27m,
    rmul=\E[24m, rs1=\Ec, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
    setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
    setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
    setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
    sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
    sgr0=\E(B\E[m, smacs=\E(0, smam=\E[?7h, smcup=\E[?1049h,
    smir=\E[4h, smkx=\E[?1h\E=, smm=\E[?1034h, smso=\E[7m,
    smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
    u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,
@remy-theroux

This comment has been minimized.

Show comment
Hide comment
@remy-theroux

remy-theroux Mar 26, 2014

Well done Ricard, i'll try next time. Now i know much more about omzsh and a little more about git.

remy-theroux commented Mar 26, 2014

Well done Ricard, i'll try next time. Now i know much more about omzsh and a little more about git.

@simonwhitaker

This comment has been minimized.

Show comment
Hide comment
@simonwhitaker

simonwhitaker Mar 27, 2014

I have a similar issue, also tracked down to the same commit with git-bisect. In my case, I have this in my .zshrc:

# Stuff before this omitted…

#--------------------------------------------------------
# Now bootstrap oh-my-zsh
#--------------------------------------------------------

source $ZSH/oh-my-zsh.sh

#--------------------------------------------------------
# Tweak oh-my-zsh default behaviour
#--------------------------------------------------------

# Fix up/down arrow behaviour to preferred weirdness
# Up/down arrows search back/forwards in the history for 
# a line beginning with the current line up to the cursor.
# This leaves the cursor in its original position.
# See zshzle(1) manpage for details.
autoload history-search-end
zle -N history-beginning-search-backward-end history-search-end
zle -N history-beginning-search-forward-end  history-search-end

bindkey '^[[A' history-beginning-search-backward-end
bindkey '^[[B' history-beginning-search-forward-end

Those bindkey commands no longer work; typing part of a command then hitting the up arrow no longer brings up the last command I typed that started with the same prefix.

simonwhitaker commented Mar 27, 2014

I have a similar issue, also tracked down to the same commit with git-bisect. In my case, I have this in my .zshrc:

# Stuff before this omitted…

#--------------------------------------------------------
# Now bootstrap oh-my-zsh
#--------------------------------------------------------

source $ZSH/oh-my-zsh.sh

#--------------------------------------------------------
# Tweak oh-my-zsh default behaviour
#--------------------------------------------------------

# Fix up/down arrow behaviour to preferred weirdness
# Up/down arrows search back/forwards in the history for 
# a line beginning with the current line up to the cursor.
# This leaves the cursor in its original position.
# See zshzle(1) manpage for details.
autoload history-search-end
zle -N history-beginning-search-backward-end history-search-end
zle -N history-beginning-search-forward-end  history-search-end

bindkey '^[[A' history-beginning-search-backward-end
bindkey '^[[B' history-beginning-search-forward-end

Those bindkey commands no longer work; typing part of a command then hitting the up arrow no longer brings up the last command I typed that started with the same prefix.

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 27, 2014

Collaborator

@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 infocmp output as I do, no idea. Maybe the commit overwrites necessary behaviour of zle-line-init and zle-line-end, try reverting it: git revert ff0cafa

Collaborator

mcornella commented Mar 27, 2014

@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 infocmp output as I do, no idea. Maybe the commit overwrites necessary behaviour of zle-line-init and zle-line-end, try reverting it: git revert ff0cafa

@simonwhitaker

This comment has been minimized.

Show comment
Hide comment
@simonwhitaker

simonwhitaker Mar 27, 2014

@simonwhitaker the issue you describe has been submitted in #1433, #2628 and #2632

Those are issues with the history-substring-search plugin, which I don't use. As noted in my comment, the issue I'm having was initiated by ff0cafa

simonwhitaker commented Mar 27, 2014

@simonwhitaker the issue you describe has been submitted in #1433, #2628 and #2632

Those are issues with the history-substring-search plugin, which I don't use. As noted in my comment, the issue I'm having was initiated by ff0cafa

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 27, 2014

Collaborator

My mistake, I read substring instead of beginning 😊 Try using the solution in #2511; in your case that would be (i think):

zmodload zsh/terminfo
bindkey "$terminfo[kcuu1]" history-beginning-search-backward-end
bindkey "$terminfo[kcud1]" history-beginning-search-forward-end
Collaborator

mcornella commented Mar 27, 2014

My mistake, I read substring instead of beginning 😊 Try using the solution in #2511; in your case that would be (i think):

zmodload zsh/terminfo
bindkey "$terminfo[kcuu1]" history-beginning-search-backward-end
bindkey "$terminfo[kcud1]" history-beginning-search-forward-end
@quicksnap

This comment has been minimized.

Show comment
Hide comment
@quicksnap

quicksnap Mar 28, 2014

I'm getting this issue as well in iTerm2, due to the same commit. I'm on OSX with the Mac extended keyboard. infocmp: https://gist.github.com/quicksnap/9837417

Anything else I can provide, let me know.. I use the numpad enter key a lot :)

quicksnap commented Mar 28, 2014

I'm getting this issue as well in iTerm2, due to the same commit. I'm on OSX with the Mac extended keyboard. infocmp: https://gist.github.com/quicksnap/9837417

Anything else I can provide, let me know.. I use the numpad enter key a lot :)

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 28, 2014

Collaborator

Ok, what we have so far:

  • Only appears with iTerm2
  • $TERM is set to 'xterm'
  • infocmp output is very similar to mine (the values that matter are the same), so it's not a terminfo problem
  • problem appears after commit ff0cafa

My guess is that iTerm2 uses a different zle-line-init and zle-line-end functions, and that the commit overriding them makes iTerm2 fail somehow.

This is your homework:

  • Revert the offending commit: git revert ff0cafa
  • Restart iTerm2
  • Output content of zle-line-init and zle-line-end: where zle-line-init && where zle-line-end

If that doesn't cut it we'll have to talk with people over at iTerm2

Collaborator

mcornella commented Mar 28, 2014

Ok, what we have so far:

  • Only appears with iTerm2
  • $TERM is set to 'xterm'
  • infocmp output is very similar to mine (the values that matter are the same), so it's not a terminfo problem
  • problem appears after commit ff0cafa

My guess is that iTerm2 uses a different zle-line-init and zle-line-end functions, and that the commit overriding them makes iTerm2 fail somehow.

This is your homework:

  • Revert the offending commit: git revert ff0cafa
  • Restart iTerm2
  • Output content of zle-line-init and zle-line-end: where zle-line-init && where zle-line-end

If that doesn't cut it we'll have to talk with people over at iTerm2

@simonwhitaker

This comment has been minimized.

Show comment
Hide comment
@simonwhitaker

simonwhitaker Mar 28, 2014

@mcornella:

Only appears with iTerm2

Nope, I'm using Terminal.app

$TERM is set to 'xterm'

Nope, mine is xterm-256color

infocmp output is very similar to mine (the values that matter are the same), so it's not a terminfo problem

Here's my infocmp output in case it's of use.

problem appears after commit ff0cafa

Correct

simonwhitaker commented Mar 28, 2014

@mcornella:

Only appears with iTerm2

Nope, I'm using Terminal.app

$TERM is set to 'xterm'

Nope, mine is xterm-256color

infocmp output is very similar to mine (the values that matter are the same), so it's not a terminfo problem

Here's my infocmp output in case it's of use.

problem appears after commit ff0cafa

Correct

@ricard33

This comment has been minimized.

Show comment
Hide comment
@ricard33

ricard33 Mar 28, 2014

After doing a git revert ff0cafa(and fixing conflicts), numeric PAD works well in iTerm2.

But zle-line-initand zle-line-end don't exist:

$ where zle-line-init
zle-line-init not found

ricard33 commented Mar 28, 2014

After doing a git revert ff0cafa(and fixing conflicts), numeric PAD works well in iTerm2.

But zle-line-initand zle-line-end don't exist:

$ where zle-line-init
zle-line-init not found
@quicksnap

This comment has been minimized.

Show comment
Hide comment
@quicksnap

quicksnap Mar 28, 2014

Same here. Reverting ff0cafa removes said functions.

quicksnap commented Mar 28, 2014

Same here. Reverting ff0cafa removes said functions.

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 28, 2014

Collaborator

@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-finish

then paste the output using where. And sorry, the correct function is zle-line-finish instead of zle-line-end.
I don't know much about terminfo and key bindings. The commit ff0cafa adds a feature best described here. I understand why that is done, but no idea why it doesn't work.

Finally, it seems prezto had the same issue.

Collaborator

mcornella commented Mar 28, 2014

@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-finish

then paste the output using where. And sorry, the correct function is zle-line-finish instead of zle-line-end.
I don't know much about terminfo and key bindings. The commit ff0cafa adds a feature best described here. I understand why that is done, but no idea why it doesn't work.

Finally, it seems prezto had the same issue.

@quicksnap

This comment has been minimized.

Show comment
Hide comment
@quicksnap

quicksnap Mar 28, 2014

% autoload -U zle-line-init && zle-line-init; autoload -U zle-line-finish && zle-line-finish
zsh: zle-line-init: function definition file not found
zsh: zle-line-finish: function definition file not found

quicksnap commented Mar 28, 2014

% autoload -U zle-line-init && zle-line-init; autoload -U zle-line-finish && zle-line-finish
zsh: zle-line-init: function definition file not found
zsh: zle-line-finish: function definition file not found
@quicksnap

This comment has been minimized.

Show comment
Hide comment
@quicksnap

quicksnap Mar 28, 2014

Also, this is my oh-my-zsh after the revert: https://gist.github.com/quicksnap/9844880

quicksnap commented Mar 28, 2014

Also, this is my oh-my-zsh after the revert: https://gist.github.com/quicksnap/9844880

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Mar 29, 2014

Collaborator

Yeah don't even bother trying what I said. It seems terminfo is a PITA everywhere [1][2]. Report your zsh versions (zsh --version) and let's wait until some consensus is made.

[1] sorin-ionescu/prezto#263
[2] sorin-ionescu/prezto#516

Collaborator

mcornella commented Mar 29, 2014

Yeah don't even bother trying what I said. It seems terminfo is a PITA everywhere [1][2]. Report your zsh versions (zsh --version) and let's wait until some consensus is made.

[1] sorin-ionescu/prezto#263
[2] sorin-ionescu/prezto#516

@j16r

This comment has been minimized.

Show comment
Hide comment
@j16r

j16r Apr 1, 2014

Contributor

Same problem for me. zsh 5.0.5 (x86_64-apple-darwin13.0.0)

Contributor

j16r commented Apr 1, 2014

Same problem for me. zsh 5.0.5 (x86_64-apple-darwin13.0.0)

@llambda

This comment has been minimized.

Show comment
Hide comment
@llambda

llambda Jul 28, 2014

Just did a git bisect. Commit ff0cafa was the culprit. Reverted it in my fork. https://github.com/llambda/oh-my-zsh

llambda commented Jul 28, 2014

Just did a git bisect. Commit ff0cafa was the culprit. Reverted it in my fork. https://github.com/llambda/oh-my-zsh

@JikkuJose

This comment has been minimized.

Show comment
Hide comment
@JikkuJose

JikkuJose Aug 16, 2014

Any ideas for Terminal in Yosemite?

JikkuJose commented Aug 16, 2014

Any ideas for Terminal in Yosemite?

@rm-bergmann

This comment has been minimized.

Show comment
Hide comment
@rm-bergmann

rm-bergmann Aug 29, 2014

I have this same problem using Putty on Windows, been driving me insane for months. When I SSH into Ubuntu with my Ubuntu user (No ZSH) numeric keypad works fine, when I sudo su as root (with ZSH) NUmeric keypad does not work.

I've gone through all putty settings to try find a fix and no luck, there must be something I can put in the .zhrc file? Any idea's?

Thanks.

rm-bergmann commented Aug 29, 2014

I have this same problem using Putty on Windows, been driving me insane for months. When I SSH into Ubuntu with my Ubuntu user (No ZSH) numeric keypad works fine, when I sudo su as root (with ZSH) NUmeric keypad does not work.

I've gone through all putty settings to try find a fix and no luck, there must be something I can put in the .zhrc file? Any idea's?

Thanks.

@rm-bergmann

This comment has been minimized.

Show comment
Hide comment
@rm-bergmann

rm-bergmann Aug 29, 2014

Ok, I found this solution and it works, maybe can be included in next update?

http://superuser.com/questions/742171/zsh-z-shell-numpad-numlock-doesnt-work

rm-bergmann commented Aug 29, 2014

Ok, I found this solution and it works, maybe can be included in next update?

http://superuser.com/questions/742171/zsh-z-shell-numpad-numlock-doesnt-work

@mcornella

This comment has been minimized.

Show comment
Hide comment
@mcornella

mcornella Sep 29, 2014

Collaborator

Yes @rm-bergmann, that could be a sensible default thanks (sorry for the delay).

I'm worried thought that those hardcoded values may not be the same for every platform / terminal emulator. See man terminfo for more information.

This could be made into a pull request to discuss further. Cheers!

Collaborator

mcornella commented Sep 29, 2014

Yes @rm-bergmann, that could be a sensible default thanks (sorry for the delay).

I'm worried thought that those hardcoded values may not be the same for every platform / terminal emulator. See man terminfo for more information.

This could be made into a pull request to discuss further. Cheers!

@mathias-baumann-sociomantic

This comment has been minimized.

Show comment
Hide comment
@mathias-baumann-sociomantic

mathias-baumann-sociomantic Sep 30, 2014

Not sure that's a good solution. This would not fix the issue if you use a none-standard layout that sends the KP_* key codes on different keys/combinations (like neo where it would be AltGr + h for 7 for example.

mathias-baumann-sociomantic commented Sep 30, 2014

Not sure that's a good solution. This would not fix the issue if you use a none-standard layout that sends the KP_* key codes on different keys/combinations (like neo where it would be AltGr + h for 7 for example.

@nucleobases

This comment has been minimized.

Show comment
Hide comment
@nucleobases

nucleobases commented Oct 1, 2014

Thanks @tomduncalf !!!!!!!

@trey

This comment has been minimized.

Show comment
Hide comment
@trey

trey commented Oct 27, 2014

This is a cool solution: http://superuser.com/a/742193/1722

@philfreo

This comment has been minimized.

Show comment
Hide comment
@philfreo

philfreo Oct 29, 2014

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
http://apple.stackexchange.com/questions/151873/yosemite-upgrade-changed-numeric-keypad-enter-key-to-issue-33om

philfreo commented Oct 29, 2014

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
http://apple.stackexchange.com/questions/151873/yosemite-upgrade-changed-numeric-keypad-enter-key-to-issue-33om

@trey

This comment has been minimized.

Show comment
Hide comment
@trey

trey Oct 30, 2014

Even better, @philfreo. Thanks!

trey commented Oct 30, 2014

Even better, @philfreo. Thanks!

trey added a commit to trey/dotfiles that referenced this issue Oct 30, 2014

Nevermind, there's an easier way.
Preferences > Advanced Tab > unchecked "Allow VT100 application keypad mode."

robbyrussell/oh-my-zsh#2654 (comment)
@mathias-baumann-sociomantic

This comment has been minimized.

Show comment
Hide comment
@mathias-baumann-sociomantic

mathias-baumann-sociomantic Oct 30, 2014

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.

mathias-baumann-sociomantic commented Oct 30, 2014

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.

@philfreo

This comment has been minimized.

Show comment
Hide comment
@philfreo

philfreo Oct 30, 2014

My guess is that an unchecked setting is what people have always run, but the upgrade to Yosemite changed the default setting of this. =

philfreo commented Oct 30, 2014

My guess is that an unchecked setting is what people have always run, but the upgrade to Yosemite changed the default setting of this. =

@leolelego

This comment has been minimized.

Show comment
Hide comment

leolelego commented Feb 3, 2015

@castortech

This comment has been minimized.

Show comment
Hide comment
@castortech

castortech Aug 1, 2015

The solution from @philfreo worked for me, thanks

castortech commented Aug 1, 2015

The solution from @philfreo worked for me, thanks

@volure

This comment has been minimized.

Show comment
Hide comment
@volure

volure Aug 4, 2015

I am on the macintosh.
This worked for me
http://superuser.com/questions/742171/zsh-z-shell-numpad-numlock-doesnt-work

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.

volure commented Aug 4, 2015

I am on the macintosh.
This worked for me
http://superuser.com/questions/742171/zsh-z-shell-numpad-numlock-doesnt-work

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.

@richstandbrook

This comment has been minimized.

Show comment
Hide comment
@richstandbrook

richstandbrook Aug 13, 2015

+1 for Unchecking VT100 in advanced preferences.

Had the key mapping working for a bit but it caused strange issues in vi read about unchecking the "Allow VT100 application keypad mode" now keypad sanity is restored.

richstandbrook commented Aug 13, 2015

+1 for Unchecking VT100 in advanced preferences.

Had the key mapping working for a bit but it caused strange issues in vi read about unchecking the "Allow VT100 application keypad mode" now keypad sanity is restored.

@apjanke apjanke referenced this issue Sep 11, 2015

Open

[Tracking] Terminal and terminfo related issues #4344

37 of 53 tasks complete
@doomsbuster

This comment has been minimized.

Show comment
Hide comment
@doomsbuster

doomsbuster Nov 22, 2015

I was wondering why the Num Pad wasnt working and i ran into this issue. The problem still persists.

doomsbuster commented Nov 22, 2015

I was wondering why the Num Pad wasnt working and i ran into this issue. The problem still persists.

@doomsbuster

This comment has been minimized.

Show comment
Hide comment
@doomsbuster

doomsbuster Nov 22, 2015

@volure you saved my day. Thank you very much. I mapped the following keys in my .zshrc and the numpad is active again.

# Keypad
# 0 . Enter
bindkey -s "^[Op" "0"
bindkey -s "^[On" "."
bindkey -s "^[OM" "^M"
# 1 2 3
bindkey -s "^[Oq" "1"
bindkey -s "^[Or" "2"
bindkey -s "^[Os" "3"
# 4 5 6
bindkey -s "^[Ot" "4"
bindkey -s "^[Ou" "5"
bindkey -s "^[Ov" "6"
# 7 8 9
bindkey -s "^[Ow" "7"
bindkey -s "^[Ox" "8"
bindkey -s "^[Oy" "9"
# + -  * / =
bindkey -s "^[Ok" "+"
bindkey -s "^[Om" "-"
bindkey -s "^[Oj" "*"
bindkey -s "^[Oo" "/"
bindkey -s "^[OX" "="

doomsbuster commented Nov 22, 2015

@volure you saved my day. Thank you very much. I mapped the following keys in my .zshrc and the numpad is active again.

# Keypad
# 0 . Enter
bindkey -s "^[Op" "0"
bindkey -s "^[On" "."
bindkey -s "^[OM" "^M"
# 1 2 3
bindkey -s "^[Oq" "1"
bindkey -s "^[Or" "2"
bindkey -s "^[Os" "3"
# 4 5 6
bindkey -s "^[Ot" "4"
bindkey -s "^[Ou" "5"
bindkey -s "^[Ov" "6"
# 7 8 9
bindkey -s "^[Ow" "7"
bindkey -s "^[Ox" "8"
bindkey -s "^[Oy" "9"
# + -  * / =
bindkey -s "^[Ok" "+"
bindkey -s "^[Om" "-"
bindkey -s "^[Oj" "*"
bindkey -s "^[Oo" "/"
bindkey -s "^[OX" "="
@apjanke

This comment has been minimized.

Show comment
Hide comment
@apjanke

apjanke Dec 15, 2015

Contributor

We should probably add these bindings by default in OMZ if we are going to be using smkx in zle-line-init. Otherwise, the numeric keypad is going to be broken by default on the command line. And going back to the numbers seems like the default most users would want.

We may not have a great way of doing this portably, though. The terminfo.src file from ncurses describes a couple layouts for the numeric keypad, with character sequences and capability names.

#   _______________________________________
#  |   PF1   |   PF2   |   PF3   |   PF4   |
#  |   $OP   |   $OQ   |   $OR   |   $OS   |
#  |_kf1__k1_|_kf2__k2_|_kf3__k3_|_kf4__k4_|
#  |    7         8         9         -    |
#  |   $Ow   |   $Ox   |   $Oy   |   $Om   |
#  |_kf9__k9_|_kf10_k;_|_kf0__k0_|_________|
#  |    4    |    5    |    6    |    ,    |
#  |   $Ot   |   $Ou   |   $Ov   |   $Ol   |
#  |_kf5__k5_|_kf6__k6_|_kf7__k7_|_kf8__k8_|
#  |    1    |    2    |    3    |         |
#  |   $Oq   |   $Or   |   $Os   |  enter  |
#  |_ka1__K1_|_kb2__K2_|_ka3__K3_|  $OM    |
#  |         0         |   .     |         |
#  |        $Op        |  $On    |         |
#  |___kc1_______K4____|_kc3__K5_|_kent_@8_|

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 smkx thing. It could be less work to handle the edge cases in cursor mode than to get everything working right in application mode.

Is there any interest in binding the numeric keypad keys to something besides numeric character entry?

Contributor

apjanke commented Dec 15, 2015

We should probably add these bindings by default in OMZ if we are going to be using smkx in zle-line-init. Otherwise, the numeric keypad is going to be broken by default on the command line. And going back to the numbers seems like the default most users would want.

We may not have a great way of doing this portably, though. The terminfo.src file from ncurses describes a couple layouts for the numeric keypad, with character sequences and capability names.

#   _______________________________________
#  |   PF1   |   PF2   |   PF3   |   PF4   |
#  |   $OP   |   $OQ   |   $OR   |   $OS   |
#  |_kf1__k1_|_kf2__k2_|_kf3__k3_|_kf4__k4_|
#  |    7         8         9         -    |
#  |   $Ow   |   $Ox   |   $Oy   |   $Om   |
#  |_kf9__k9_|_kf10_k;_|_kf0__k0_|_________|
#  |    4    |    5    |    6    |    ,    |
#  |   $Ot   |   $Ou   |   $Ov   |   $Ol   |
#  |_kf5__k5_|_kf6__k6_|_kf7__k7_|_kf8__k8_|
#  |    1    |    2    |    3    |         |
#  |   $Oq   |   $Or   |   $Os   |  enter  |
#  |_ka1__K1_|_kb2__K2_|_ka3__K3_|  $OM    |
#  |         0         |   .     |         |
#  |        $Op        |  $On    |         |
#  |___kc1_______K4____|_kc3__K5_|_kent_@8_|

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 smkx thing. It could be less work to handle the edge cases in cursor mode than to get everything working right in application mode.

Is there any interest in binding the numeric keypad keys to something besides numeric character entry?

@mcornella mcornella added the bindkey label Dec 15, 2015

@mcornella mcornella reopened this Dec 15, 2015

@shaharmor

This comment has been minimized.

Show comment
Hide comment
@shaharmor

shaharmor Mar 28, 2016

This should definitely be default

shaharmor commented Mar 28, 2016

This should definitely be default

@kachkaev

This comment has been minimized.

Show comment
Hide comment
@kachkaev

kachkaev May 6, 2016

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.

kachkaev commented May 6, 2016

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.

@christoga

This comment has been minimized.

Show comment
Hide comment
@christoga

christoga May 6, 2016

Yeah, I'm suprised. @kachkaev

christoga commented May 6, 2016

Yeah, I'm suprised. @kachkaev

@apjanke

This comment has been minimized.

Show comment
Hide comment
@apjanke

apjanke May 6, 2016

Contributor

What is the benefit of keeping the num pad not working?

It's tied in to the smkx/rmkx stuff that allows OMZ to use terminfo to do portable key mappings, instead of hardcoded key sequences (which don't work in all terminals) or maintaining OMZ's own terminal key mapping database. An unfortunate side effect due to terminfo's coarse granularity for keypad mode controls.

At this point I'm thinking the solution is to ditch smkx/rmkx.

Contributor

apjanke commented May 6, 2016

What is the benefit of keeping the num pad not working?

It's tied in to the smkx/rmkx stuff that allows OMZ to use terminfo to do portable key mappings, instead of hardcoded key sequences (which don't work in all terminals) or maintaining OMZ's own terminal key mapping database. An unfortunate side effect due to terminfo's coarse granularity for keypad mode controls.

At this point I'm thinking the solution is to ditch smkx/rmkx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment