Arrow keys spontaneously stop working in vim
Clash Royale CLAN TAG#URR8PPP
up vote
23
down vote
favorite
I recently upgraded from OS X 10.6 (I think) to 10.9. Since then it seems, while editing in vim
, the arrow keys will "spontaneously" stop working.
At one point, in frustration I "mashed" one of the arrow keys and was eventually shown a "E388 Couldn't find a definition" error. All other times I've experienced it, the arrows, having worked for awhile, suddenly start dinging at me!
Quitting and reopening solves the problem temporarily. But, I'd like to prevent it!
Anyone know what this might be? And how to fix it?
It looks like my default vimrc
was modified during the update. If my memory is correct, it was a pretty big file previously. Now, it just contains this:
" Configuration file for vim
set modelines=0 " CVE-2007-2438
" Normally we use vim-extensions. If you want true vi-compatibility
" remove change the following statements
set nocompatible " Use Vim defaults instead of 100% vi compatibility
set backspace=2 " more powerful backspacing
" Don't write backup file if vim is being called by "crontab -e"
au BufWrite /private/tmp/crontab.* set nowritebackup
" Don't write backup file if vim is being called by "chpass"
au BufWrite /private/etc/pw.* set nowritebackup
I have no idea what these options do yet. I'll look into it -- but, hopefully someone here knows more quickly than I can google and read ...
vim
 |Â
show 4 more comments
up vote
23
down vote
favorite
I recently upgraded from OS X 10.6 (I think) to 10.9. Since then it seems, while editing in vim
, the arrow keys will "spontaneously" stop working.
At one point, in frustration I "mashed" one of the arrow keys and was eventually shown a "E388 Couldn't find a definition" error. All other times I've experienced it, the arrows, having worked for awhile, suddenly start dinging at me!
Quitting and reopening solves the problem temporarily. But, I'd like to prevent it!
Anyone know what this might be? And how to fix it?
It looks like my default vimrc
was modified during the update. If my memory is correct, it was a pretty big file previously. Now, it just contains this:
" Configuration file for vim
set modelines=0 " CVE-2007-2438
" Normally we use vim-extensions. If you want true vi-compatibility
" remove change the following statements
set nocompatible " Use Vim defaults instead of 100% vi compatibility
set backspace=2 " more powerful backspacing
" Don't write backup file if vim is being called by "crontab -e"
au BufWrite /private/tmp/crontab.* set nowritebackup
" Don't write backup file if vim is being called by "chpass"
au BufWrite /private/etc/pw.* set nowritebackup
I have no idea what these options do yet. I'll look into it -- but, hopefully someone here knows more quickly than I can google and read ...
vim
I also just realized there's an Apple-centric forum here that this question might be better suited for. So, if this is more likely a condition of OS X thanvim
, perhaps a mod could migrate this for me.
â svidgen
Feb 22 '14 at 3:55
1
Reminds me of working on a "Prime" mainframe in college. The professor taught that you should never use the arrow keys invi
. Always use hjkl. That's where the "arrow" keys use to be on ancient hardware.
â Red Cricket
Feb 22 '14 at 3:56
OK... But, the arrow keys should work. Regardless of whether your professor thinks I should use them. And I find them convenient at times. So, looking forward to see the solution.
â svidgen
Feb 22 '14 at 15:28
1
what happens when you insert the key literal into a buffer? go into insert mode, and press Ctrl+v, then an arrow key. Vim on my Mac shows the up arrow key as^[OA
, down as^[OB
, right as^[OC
, and left as^[OD
. check before and after the problem presents itself
â Nathan Wallace
Feb 26 '14 at 18:21
@NathanWallace not sure how I overlooked your question. I'll try that when I'm at my Mac next.
â svidgen
Mar 4 '14 at 4:53
 |Â
show 4 more comments
up vote
23
down vote
favorite
up vote
23
down vote
favorite
I recently upgraded from OS X 10.6 (I think) to 10.9. Since then it seems, while editing in vim
, the arrow keys will "spontaneously" stop working.
At one point, in frustration I "mashed" one of the arrow keys and was eventually shown a "E388 Couldn't find a definition" error. All other times I've experienced it, the arrows, having worked for awhile, suddenly start dinging at me!
Quitting and reopening solves the problem temporarily. But, I'd like to prevent it!
Anyone know what this might be? And how to fix it?
It looks like my default vimrc
was modified during the update. If my memory is correct, it was a pretty big file previously. Now, it just contains this:
" Configuration file for vim
set modelines=0 " CVE-2007-2438
" Normally we use vim-extensions. If you want true vi-compatibility
" remove change the following statements
set nocompatible " Use Vim defaults instead of 100% vi compatibility
set backspace=2 " more powerful backspacing
" Don't write backup file if vim is being called by "crontab -e"
au BufWrite /private/tmp/crontab.* set nowritebackup
" Don't write backup file if vim is being called by "chpass"
au BufWrite /private/etc/pw.* set nowritebackup
I have no idea what these options do yet. I'll look into it -- but, hopefully someone here knows more quickly than I can google and read ...
vim
I recently upgraded from OS X 10.6 (I think) to 10.9. Since then it seems, while editing in vim
, the arrow keys will "spontaneously" stop working.
At one point, in frustration I "mashed" one of the arrow keys and was eventually shown a "E388 Couldn't find a definition" error. All other times I've experienced it, the arrows, having worked for awhile, suddenly start dinging at me!
Quitting and reopening solves the problem temporarily. But, I'd like to prevent it!
Anyone know what this might be? And how to fix it?
It looks like my default vimrc
was modified during the update. If my memory is correct, it was a pretty big file previously. Now, it just contains this:
" Configuration file for vim
set modelines=0 " CVE-2007-2438
" Normally we use vim-extensions. If you want true vi-compatibility
" remove change the following statements
set nocompatible " Use Vim defaults instead of 100% vi compatibility
set backspace=2 " more powerful backspacing
" Don't write backup file if vim is being called by "crontab -e"
au BufWrite /private/tmp/crontab.* set nowritebackup
" Don't write backup file if vim is being called by "chpass"
au BufWrite /private/etc/pw.* set nowritebackup
I have no idea what these options do yet. I'll look into it -- but, hopefully someone here knows more quickly than I can google and read ...
vim
vim
edited Mar 5 '14 at 2:52
asked Feb 22 '14 at 3:50
svidgen
188119
188119
I also just realized there's an Apple-centric forum here that this question might be better suited for. So, if this is more likely a condition of OS X thanvim
, perhaps a mod could migrate this for me.
â svidgen
Feb 22 '14 at 3:55
1
Reminds me of working on a "Prime" mainframe in college. The professor taught that you should never use the arrow keys invi
. Always use hjkl. That's where the "arrow" keys use to be on ancient hardware.
â Red Cricket
Feb 22 '14 at 3:56
OK... But, the arrow keys should work. Regardless of whether your professor thinks I should use them. And I find them convenient at times. So, looking forward to see the solution.
â svidgen
Feb 22 '14 at 15:28
1
what happens when you insert the key literal into a buffer? go into insert mode, and press Ctrl+v, then an arrow key. Vim on my Mac shows the up arrow key as^[OA
, down as^[OB
, right as^[OC
, and left as^[OD
. check before and after the problem presents itself
â Nathan Wallace
Feb 26 '14 at 18:21
@NathanWallace not sure how I overlooked your question. I'll try that when I'm at my Mac next.
â svidgen
Mar 4 '14 at 4:53
 |Â
show 4 more comments
I also just realized there's an Apple-centric forum here that this question might be better suited for. So, if this is more likely a condition of OS X thanvim
, perhaps a mod could migrate this for me.
â svidgen
Feb 22 '14 at 3:55
1
Reminds me of working on a "Prime" mainframe in college. The professor taught that you should never use the arrow keys invi
. Always use hjkl. That's where the "arrow" keys use to be on ancient hardware.
â Red Cricket
Feb 22 '14 at 3:56
OK... But, the arrow keys should work. Regardless of whether your professor thinks I should use them. And I find them convenient at times. So, looking forward to see the solution.
â svidgen
Feb 22 '14 at 15:28
1
what happens when you insert the key literal into a buffer? go into insert mode, and press Ctrl+v, then an arrow key. Vim on my Mac shows the up arrow key as^[OA
, down as^[OB
, right as^[OC
, and left as^[OD
. check before and after the problem presents itself
â Nathan Wallace
Feb 26 '14 at 18:21
@NathanWallace not sure how I overlooked your question. I'll try that when I'm at my Mac next.
â svidgen
Mar 4 '14 at 4:53
I also just realized there's an Apple-centric forum here that this question might be better suited for. So, if this is more likely a condition of OS X than
vim
, perhaps a mod could migrate this for me.â svidgen
Feb 22 '14 at 3:55
I also just realized there's an Apple-centric forum here that this question might be better suited for. So, if this is more likely a condition of OS X than
vim
, perhaps a mod could migrate this for me.â svidgen
Feb 22 '14 at 3:55
1
1
Reminds me of working on a "Prime" mainframe in college. The professor taught that you should never use the arrow keys in
vi
. Always use hjkl. That's where the "arrow" keys use to be on ancient hardware.â Red Cricket
Feb 22 '14 at 3:56
Reminds me of working on a "Prime" mainframe in college. The professor taught that you should never use the arrow keys in
vi
. Always use hjkl. That's where the "arrow" keys use to be on ancient hardware.â Red Cricket
Feb 22 '14 at 3:56
OK... But, the arrow keys should work. Regardless of whether your professor thinks I should use them. And I find them convenient at times. So, looking forward to see the solution.
â svidgen
Feb 22 '14 at 15:28
OK... But, the arrow keys should work. Regardless of whether your professor thinks I should use them. And I find them convenient at times. So, looking forward to see the solution.
â svidgen
Feb 22 '14 at 15:28
1
1
what happens when you insert the key literal into a buffer? go into insert mode, and press Ctrl+v, then an arrow key. Vim on my Mac shows the up arrow key as
^[OA
, down as ^[OB
, right as ^[OC
, and left as ^[OD
. check before and after the problem presents itselfâ Nathan Wallace
Feb 26 '14 at 18:21
what happens when you insert the key literal into a buffer? go into insert mode, and press Ctrl+v, then an arrow key. Vim on my Mac shows the up arrow key as
^[OA
, down as ^[OB
, right as ^[OC
, and left as ^[OD
. check before and after the problem presents itselfâ Nathan Wallace
Feb 26 '14 at 18:21
@NathanWallace not sure how I overlooked your question. I'll try that when I'm at my Mac next.
â svidgen
Mar 4 '14 at 4:53
@NathanWallace not sure how I overlooked your question. I'll try that when I'm at my Mac next.
â svidgen
Mar 4 '14 at 4:53
 |Â
show 4 more comments
7 Answers
7
active
oldest
votes
up vote
21
down vote
accepted
Found in James Hodgkinson's blog, the following command works for me. Note it will refresh the vim screen.
:!reset
Not sure how I overlooked this answer, but it looks very promising!
â svidgen
Mar 17 '15 at 17:07
In fact ... Hitting Ctrl+R as described in the article reproduces the issue in full consistency with the wrong arrow-key mappings noted in my response to Nathan above. And the reset command solves it in that case. And .. I can't reliably reproduce the problem any other way, so this is definitely the most useful answer!
â svidgen
Mar 17 '15 at 17:15
add a comment |Â
up vote
10
down vote
I have run into this problem a few times as well. I happened to be running the screen program on another computer I was logged in to via ssh. to fix the problem I detached my screen(s), ^a d
, logged off of the machine, logged back in, and reattached screen -x
. It may work without logging off of the machine, just by detaching and reattaching screen, I cannot remember though.
Closing my screen session and restarting it fixed it for me.
â Eno
Aug 12 '15 at 18:50
that was the problem for me. Somehowscreen
got in a state of funk (over an ssh connection). Closing that terminal, then ssh again, andscreen -rd
did the trick. Thanks!
â Pierre D
Mar 31 '16 at 12:40
add a comment |Â
up vote
3
down vote
This sounds very much like your issue. The article is titled: Cursor Keys in Vim: You MacâÂÂing Me Crazy!.
excerpt
Vim is useful in many situations, particularly for quick edits (especially as root), and editing files on a remote server. One annoyance I've had during my nine months with a Mac Book Pro is cursor keys in Vim ringing the bell in both insert or command mode instead of changing lines. Upgrading to version 7 via MacPorts yielded the same results. The cursor keys worked after switching my TERM to VT220 from rxvt! The downside was syntax highlighting stopped working.
Luckily, adding VT220 to my Google search parameters turned up a reference to vt100-cursor-keys in the Vim documentation. Add the following code to your .vimrc file to fix the problem:
:set notimeout " don't timeout on mappings
:set ttimeout " do timeout on terminal key codes
:set timeoutlen=100 " timeout after 100 msec
In the same article there's another suggestion of setting your $TERM
to linux
instead on OSX.
excerpt
A better solution is to change the default value for TERM to either linux or dtterm since the TERM value will be picked up on the remote server. In this day and age, I would bet most servers support both these terminal types.
Hmm ... I'm even more confused now. I'd thought I had global/default.vimrc
files. Would these have been moved or removed during an OS X update?
â svidgen
Mar 5 '14 at 2:35
@svidgen - No I don't think that would've changed, but that issue sounded er-rely similar to yours, and the fix is easy enough to try out, so I thought I'd share it with you. Incidentally the$TERM
could've gotten changed on you.
â slmâ¦
Mar 5 '14 at 2:39
Whelp, this is definitely the most relevant answer here. +1 for that. Not sure whether it fixes it yet, unfortunately, since I can't consistently reproduce the problem.
â svidgen
Mar 5 '14 at 3:07
After having applied this fix, the issue has occurred again. Still a relevant answer, leaving the +1. But, please see my comment above if you're interested in supplying an additional answer.
â svidgen
Mar 9 '14 at 3:43
add a comment |Â
up vote
1
down vote
In the path /usr/share/vim/
I found the .vimrc
file... There I added the line
set term=ansi
It worked for me. Now the arrow keys are working properly in Vim editor.
This fixed it for me too, since latest Windows 10 WSL/Ubuntu update broke it.
â Gray Fox
May 27 at 16:25
add a comment |Â
up vote
0
down vote
Congrats on the update. I did my own update over the weekend and have been dealing with some of my own odd keyboard issues.
Here are a couple of things I needed to to:
- Remove old Logitech gaming software and upgrade. Prior to doing this I was having issues using my square and curly braces. Special keys often send esc-[ sequences in the VIM context so this might be relevant.
- Go into System Prefs:Security and Privacy:Privacy:Accessibility and enable a couple of apps (synergy_server and Logitech gaming software). Prior to this change I was unable to control my other computers with synergy or use macros with my G11. I doubt this is a direct connection for you but the Accessibility options are new and might apply to some other app of yours.
add a comment |Â
up vote
0
down vote
If you are working in .sql
files in vim
(you don't mention) this could help you. I just dealt with this the other day.
In file ~/.vimrc
let g:omni_sql_no_default_maps = 1
this particular issue is discussed here
If you're not experiencing this problem with .sql
files in vim
then I apologize, my only thought would be to verify the mapping within vim
when the problem occurs.
:map Ctrl V âÂÂ
when you lose your ability to use your arrow, do that command and see if the mapping disappeared. if it did, this gives you a place to start digging in.
add a comment |Â
up vote
0
down vote
I had this problem in an SSH session and solved it by logging out then back in again:
exit
ssh ...
Thanks for weighing in. The selected answer has consistently worked for me though. Have you tried it?
â svidgen
48 secs ago
add a comment |Â
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
21
down vote
accepted
Found in James Hodgkinson's blog, the following command works for me. Note it will refresh the vim screen.
:!reset
Not sure how I overlooked this answer, but it looks very promising!
â svidgen
Mar 17 '15 at 17:07
In fact ... Hitting Ctrl+R as described in the article reproduces the issue in full consistency with the wrong arrow-key mappings noted in my response to Nathan above. And the reset command solves it in that case. And .. I can't reliably reproduce the problem any other way, so this is definitely the most useful answer!
â svidgen
Mar 17 '15 at 17:15
add a comment |Â
up vote
21
down vote
accepted
Found in James Hodgkinson's blog, the following command works for me. Note it will refresh the vim screen.
:!reset
Not sure how I overlooked this answer, but it looks very promising!
â svidgen
Mar 17 '15 at 17:07
In fact ... Hitting Ctrl+R as described in the article reproduces the issue in full consistency with the wrong arrow-key mappings noted in my response to Nathan above. And the reset command solves it in that case. And .. I can't reliably reproduce the problem any other way, so this is definitely the most useful answer!
â svidgen
Mar 17 '15 at 17:15
add a comment |Â
up vote
21
down vote
accepted
up vote
21
down vote
accepted
Found in James Hodgkinson's blog, the following command works for me. Note it will refresh the vim screen.
:!reset
Found in James Hodgkinson's blog, the following command works for me. Note it will refresh the vim screen.
:!reset
edited Nov 10 '17 at 13:44
Zanna
2,4511023
2,4511023
answered Dec 23 '14 at 6:59
ronnefeldt
32623
32623
Not sure how I overlooked this answer, but it looks very promising!
â svidgen
Mar 17 '15 at 17:07
In fact ... Hitting Ctrl+R as described in the article reproduces the issue in full consistency with the wrong arrow-key mappings noted in my response to Nathan above. And the reset command solves it in that case. And .. I can't reliably reproduce the problem any other way, so this is definitely the most useful answer!
â svidgen
Mar 17 '15 at 17:15
add a comment |Â
Not sure how I overlooked this answer, but it looks very promising!
â svidgen
Mar 17 '15 at 17:07
In fact ... Hitting Ctrl+R as described in the article reproduces the issue in full consistency with the wrong arrow-key mappings noted in my response to Nathan above. And the reset command solves it in that case. And .. I can't reliably reproduce the problem any other way, so this is definitely the most useful answer!
â svidgen
Mar 17 '15 at 17:15
Not sure how I overlooked this answer, but it looks very promising!
â svidgen
Mar 17 '15 at 17:07
Not sure how I overlooked this answer, but it looks very promising!
â svidgen
Mar 17 '15 at 17:07
In fact ... Hitting Ctrl+R as described in the article reproduces the issue in full consistency with the wrong arrow-key mappings noted in my response to Nathan above. And the reset command solves it in that case. And .. I can't reliably reproduce the problem any other way, so this is definitely the most useful answer!
â svidgen
Mar 17 '15 at 17:15
In fact ... Hitting Ctrl+R as described in the article reproduces the issue in full consistency with the wrong arrow-key mappings noted in my response to Nathan above. And the reset command solves it in that case. And .. I can't reliably reproduce the problem any other way, so this is definitely the most useful answer!
â svidgen
Mar 17 '15 at 17:15
add a comment |Â
up vote
10
down vote
I have run into this problem a few times as well. I happened to be running the screen program on another computer I was logged in to via ssh. to fix the problem I detached my screen(s), ^a d
, logged off of the machine, logged back in, and reattached screen -x
. It may work without logging off of the machine, just by detaching and reattaching screen, I cannot remember though.
Closing my screen session and restarting it fixed it for me.
â Eno
Aug 12 '15 at 18:50
that was the problem for me. Somehowscreen
got in a state of funk (over an ssh connection). Closing that terminal, then ssh again, andscreen -rd
did the trick. Thanks!
â Pierre D
Mar 31 '16 at 12:40
add a comment |Â
up vote
10
down vote
I have run into this problem a few times as well. I happened to be running the screen program on another computer I was logged in to via ssh. to fix the problem I detached my screen(s), ^a d
, logged off of the machine, logged back in, and reattached screen -x
. It may work without logging off of the machine, just by detaching and reattaching screen, I cannot remember though.
Closing my screen session and restarting it fixed it for me.
â Eno
Aug 12 '15 at 18:50
that was the problem for me. Somehowscreen
got in a state of funk (over an ssh connection). Closing that terminal, then ssh again, andscreen -rd
did the trick. Thanks!
â Pierre D
Mar 31 '16 at 12:40
add a comment |Â
up vote
10
down vote
up vote
10
down vote
I have run into this problem a few times as well. I happened to be running the screen program on another computer I was logged in to via ssh. to fix the problem I detached my screen(s), ^a d
, logged off of the machine, logged back in, and reattached screen -x
. It may work without logging off of the machine, just by detaching and reattaching screen, I cannot remember though.
I have run into this problem a few times as well. I happened to be running the screen program on another computer I was logged in to via ssh. to fix the problem I detached my screen(s), ^a d
, logged off of the machine, logged back in, and reattached screen -x
. It may work without logging off of the machine, just by detaching and reattaching screen, I cannot remember though.
answered Mar 17 '15 at 16:58
Tyson
10112
10112
Closing my screen session and restarting it fixed it for me.
â Eno
Aug 12 '15 at 18:50
that was the problem for me. Somehowscreen
got in a state of funk (over an ssh connection). Closing that terminal, then ssh again, andscreen -rd
did the trick. Thanks!
â Pierre D
Mar 31 '16 at 12:40
add a comment |Â
Closing my screen session and restarting it fixed it for me.
â Eno
Aug 12 '15 at 18:50
that was the problem for me. Somehowscreen
got in a state of funk (over an ssh connection). Closing that terminal, then ssh again, andscreen -rd
did the trick. Thanks!
â Pierre D
Mar 31 '16 at 12:40
Closing my screen session and restarting it fixed it for me.
â Eno
Aug 12 '15 at 18:50
Closing my screen session and restarting it fixed it for me.
â Eno
Aug 12 '15 at 18:50
that was the problem for me. Somehow
screen
got in a state of funk (over an ssh connection). Closing that terminal, then ssh again, and screen -rd
did the trick. Thanks!â Pierre D
Mar 31 '16 at 12:40
that was the problem for me. Somehow
screen
got in a state of funk (over an ssh connection). Closing that terminal, then ssh again, and screen -rd
did the trick. Thanks!â Pierre D
Mar 31 '16 at 12:40
add a comment |Â
up vote
3
down vote
This sounds very much like your issue. The article is titled: Cursor Keys in Vim: You MacâÂÂing Me Crazy!.
excerpt
Vim is useful in many situations, particularly for quick edits (especially as root), and editing files on a remote server. One annoyance I've had during my nine months with a Mac Book Pro is cursor keys in Vim ringing the bell in both insert or command mode instead of changing lines. Upgrading to version 7 via MacPorts yielded the same results. The cursor keys worked after switching my TERM to VT220 from rxvt! The downside was syntax highlighting stopped working.
Luckily, adding VT220 to my Google search parameters turned up a reference to vt100-cursor-keys in the Vim documentation. Add the following code to your .vimrc file to fix the problem:
:set notimeout " don't timeout on mappings
:set ttimeout " do timeout on terminal key codes
:set timeoutlen=100 " timeout after 100 msec
In the same article there's another suggestion of setting your $TERM
to linux
instead on OSX.
excerpt
A better solution is to change the default value for TERM to either linux or dtterm since the TERM value will be picked up on the remote server. In this day and age, I would bet most servers support both these terminal types.
Hmm ... I'm even more confused now. I'd thought I had global/default.vimrc
files. Would these have been moved or removed during an OS X update?
â svidgen
Mar 5 '14 at 2:35
@svidgen - No I don't think that would've changed, but that issue sounded er-rely similar to yours, and the fix is easy enough to try out, so I thought I'd share it with you. Incidentally the$TERM
could've gotten changed on you.
â slmâ¦
Mar 5 '14 at 2:39
Whelp, this is definitely the most relevant answer here. +1 for that. Not sure whether it fixes it yet, unfortunately, since I can't consistently reproduce the problem.
â svidgen
Mar 5 '14 at 3:07
After having applied this fix, the issue has occurred again. Still a relevant answer, leaving the +1. But, please see my comment above if you're interested in supplying an additional answer.
â svidgen
Mar 9 '14 at 3:43
add a comment |Â
up vote
3
down vote
This sounds very much like your issue. The article is titled: Cursor Keys in Vim: You MacâÂÂing Me Crazy!.
excerpt
Vim is useful in many situations, particularly for quick edits (especially as root), and editing files on a remote server. One annoyance I've had during my nine months with a Mac Book Pro is cursor keys in Vim ringing the bell in both insert or command mode instead of changing lines. Upgrading to version 7 via MacPorts yielded the same results. The cursor keys worked after switching my TERM to VT220 from rxvt! The downside was syntax highlighting stopped working.
Luckily, adding VT220 to my Google search parameters turned up a reference to vt100-cursor-keys in the Vim documentation. Add the following code to your .vimrc file to fix the problem:
:set notimeout " don't timeout on mappings
:set ttimeout " do timeout on terminal key codes
:set timeoutlen=100 " timeout after 100 msec
In the same article there's another suggestion of setting your $TERM
to linux
instead on OSX.
excerpt
A better solution is to change the default value for TERM to either linux or dtterm since the TERM value will be picked up on the remote server. In this day and age, I would bet most servers support both these terminal types.
Hmm ... I'm even more confused now. I'd thought I had global/default.vimrc
files. Would these have been moved or removed during an OS X update?
â svidgen
Mar 5 '14 at 2:35
@svidgen - No I don't think that would've changed, but that issue sounded er-rely similar to yours, and the fix is easy enough to try out, so I thought I'd share it with you. Incidentally the$TERM
could've gotten changed on you.
â slmâ¦
Mar 5 '14 at 2:39
Whelp, this is definitely the most relevant answer here. +1 for that. Not sure whether it fixes it yet, unfortunately, since I can't consistently reproduce the problem.
â svidgen
Mar 5 '14 at 3:07
After having applied this fix, the issue has occurred again. Still a relevant answer, leaving the +1. But, please see my comment above if you're interested in supplying an additional answer.
â svidgen
Mar 9 '14 at 3:43
add a comment |Â
up vote
3
down vote
up vote
3
down vote
This sounds very much like your issue. The article is titled: Cursor Keys in Vim: You MacâÂÂing Me Crazy!.
excerpt
Vim is useful in many situations, particularly for quick edits (especially as root), and editing files on a remote server. One annoyance I've had during my nine months with a Mac Book Pro is cursor keys in Vim ringing the bell in both insert or command mode instead of changing lines. Upgrading to version 7 via MacPorts yielded the same results. The cursor keys worked after switching my TERM to VT220 from rxvt! The downside was syntax highlighting stopped working.
Luckily, adding VT220 to my Google search parameters turned up a reference to vt100-cursor-keys in the Vim documentation. Add the following code to your .vimrc file to fix the problem:
:set notimeout " don't timeout on mappings
:set ttimeout " do timeout on terminal key codes
:set timeoutlen=100 " timeout after 100 msec
In the same article there's another suggestion of setting your $TERM
to linux
instead on OSX.
excerpt
A better solution is to change the default value for TERM to either linux or dtterm since the TERM value will be picked up on the remote server. In this day and age, I would bet most servers support both these terminal types.
This sounds very much like your issue. The article is titled: Cursor Keys in Vim: You MacâÂÂing Me Crazy!.
excerpt
Vim is useful in many situations, particularly for quick edits (especially as root), and editing files on a remote server. One annoyance I've had during my nine months with a Mac Book Pro is cursor keys in Vim ringing the bell in both insert or command mode instead of changing lines. Upgrading to version 7 via MacPorts yielded the same results. The cursor keys worked after switching my TERM to VT220 from rxvt! The downside was syntax highlighting stopped working.
Luckily, adding VT220 to my Google search parameters turned up a reference to vt100-cursor-keys in the Vim documentation. Add the following code to your .vimrc file to fix the problem:
:set notimeout " don't timeout on mappings
:set ttimeout " do timeout on terminal key codes
:set timeoutlen=100 " timeout after 100 msec
In the same article there's another suggestion of setting your $TERM
to linux
instead on OSX.
excerpt
A better solution is to change the default value for TERM to either linux or dtterm since the TERM value will be picked up on the remote server. In this day and age, I would bet most servers support both these terminal types.
edited Dec 23 '14 at 7:00
jasonwryan
48k14132181
48k14132181
answered Mar 5 '14 at 1:42
slmâ¦
241k66501669
241k66501669
Hmm ... I'm even more confused now. I'd thought I had global/default.vimrc
files. Would these have been moved or removed during an OS X update?
â svidgen
Mar 5 '14 at 2:35
@svidgen - No I don't think that would've changed, but that issue sounded er-rely similar to yours, and the fix is easy enough to try out, so I thought I'd share it with you. Incidentally the$TERM
could've gotten changed on you.
â slmâ¦
Mar 5 '14 at 2:39
Whelp, this is definitely the most relevant answer here. +1 for that. Not sure whether it fixes it yet, unfortunately, since I can't consistently reproduce the problem.
â svidgen
Mar 5 '14 at 3:07
After having applied this fix, the issue has occurred again. Still a relevant answer, leaving the +1. But, please see my comment above if you're interested in supplying an additional answer.
â svidgen
Mar 9 '14 at 3:43
add a comment |Â
Hmm ... I'm even more confused now. I'd thought I had global/default.vimrc
files. Would these have been moved or removed during an OS X update?
â svidgen
Mar 5 '14 at 2:35
@svidgen - No I don't think that would've changed, but that issue sounded er-rely similar to yours, and the fix is easy enough to try out, so I thought I'd share it with you. Incidentally the$TERM
could've gotten changed on you.
â slmâ¦
Mar 5 '14 at 2:39
Whelp, this is definitely the most relevant answer here. +1 for that. Not sure whether it fixes it yet, unfortunately, since I can't consistently reproduce the problem.
â svidgen
Mar 5 '14 at 3:07
After having applied this fix, the issue has occurred again. Still a relevant answer, leaving the +1. But, please see my comment above if you're interested in supplying an additional answer.
â svidgen
Mar 9 '14 at 3:43
Hmm ... I'm even more confused now. I'd thought I had global/default
.vimrc
files. Would these have been moved or removed during an OS X update?â svidgen
Mar 5 '14 at 2:35
Hmm ... I'm even more confused now. I'd thought I had global/default
.vimrc
files. Would these have been moved or removed during an OS X update?â svidgen
Mar 5 '14 at 2:35
@svidgen - No I don't think that would've changed, but that issue sounded er-rely similar to yours, and the fix is easy enough to try out, so I thought I'd share it with you. Incidentally the
$TERM
could've gotten changed on you.â slmâ¦
Mar 5 '14 at 2:39
@svidgen - No I don't think that would've changed, but that issue sounded er-rely similar to yours, and the fix is easy enough to try out, so I thought I'd share it with you. Incidentally the
$TERM
could've gotten changed on you.â slmâ¦
Mar 5 '14 at 2:39
Whelp, this is definitely the most relevant answer here. +1 for that. Not sure whether it fixes it yet, unfortunately, since I can't consistently reproduce the problem.
â svidgen
Mar 5 '14 at 3:07
Whelp, this is definitely the most relevant answer here. +1 for that. Not sure whether it fixes it yet, unfortunately, since I can't consistently reproduce the problem.
â svidgen
Mar 5 '14 at 3:07
After having applied this fix, the issue has occurred again. Still a relevant answer, leaving the +1. But, please see my comment above if you're interested in supplying an additional answer.
â svidgen
Mar 9 '14 at 3:43
After having applied this fix, the issue has occurred again. Still a relevant answer, leaving the +1. But, please see my comment above if you're interested in supplying an additional answer.
â svidgen
Mar 9 '14 at 3:43
add a comment |Â
up vote
1
down vote
In the path /usr/share/vim/
I found the .vimrc
file... There I added the line
set term=ansi
It worked for me. Now the arrow keys are working properly in Vim editor.
This fixed it for me too, since latest Windows 10 WSL/Ubuntu update broke it.
â Gray Fox
May 27 at 16:25
add a comment |Â
up vote
1
down vote
In the path /usr/share/vim/
I found the .vimrc
file... There I added the line
set term=ansi
It worked for me. Now the arrow keys are working properly in Vim editor.
This fixed it for me too, since latest Windows 10 WSL/Ubuntu update broke it.
â Gray Fox
May 27 at 16:25
add a comment |Â
up vote
1
down vote
up vote
1
down vote
In the path /usr/share/vim/
I found the .vimrc
file... There I added the line
set term=ansi
It worked for me. Now the arrow keys are working properly in Vim editor.
In the path /usr/share/vim/
I found the .vimrc
file... There I added the line
set term=ansi
It worked for me. Now the arrow keys are working properly in Vim editor.
edited Nov 10 '17 at 13:45
Zanna
2,4511023
2,4511023
answered Nov 10 '17 at 11:59
Anup Kumar
111
111
This fixed it for me too, since latest Windows 10 WSL/Ubuntu update broke it.
â Gray Fox
May 27 at 16:25
add a comment |Â
This fixed it for me too, since latest Windows 10 WSL/Ubuntu update broke it.
â Gray Fox
May 27 at 16:25
This fixed it for me too, since latest Windows 10 WSL/Ubuntu update broke it.
â Gray Fox
May 27 at 16:25
This fixed it for me too, since latest Windows 10 WSL/Ubuntu update broke it.
â Gray Fox
May 27 at 16:25
add a comment |Â
up vote
0
down vote
Congrats on the update. I did my own update over the weekend and have been dealing with some of my own odd keyboard issues.
Here are a couple of things I needed to to:
- Remove old Logitech gaming software and upgrade. Prior to doing this I was having issues using my square and curly braces. Special keys often send esc-[ sequences in the VIM context so this might be relevant.
- Go into System Prefs:Security and Privacy:Privacy:Accessibility and enable a couple of apps (synergy_server and Logitech gaming software). Prior to this change I was unable to control my other computers with synergy or use macros with my G11. I doubt this is a direct connection for you but the Accessibility options are new and might apply to some other app of yours.
add a comment |Â
up vote
0
down vote
Congrats on the update. I did my own update over the weekend and have been dealing with some of my own odd keyboard issues.
Here are a couple of things I needed to to:
- Remove old Logitech gaming software and upgrade. Prior to doing this I was having issues using my square and curly braces. Special keys often send esc-[ sequences in the VIM context so this might be relevant.
- Go into System Prefs:Security and Privacy:Privacy:Accessibility and enable a couple of apps (synergy_server and Logitech gaming software). Prior to this change I was unable to control my other computers with synergy or use macros with my G11. I doubt this is a direct connection for you but the Accessibility options are new and might apply to some other app of yours.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Congrats on the update. I did my own update over the weekend and have been dealing with some of my own odd keyboard issues.
Here are a couple of things I needed to to:
- Remove old Logitech gaming software and upgrade. Prior to doing this I was having issues using my square and curly braces. Special keys often send esc-[ sequences in the VIM context so this might be relevant.
- Go into System Prefs:Security and Privacy:Privacy:Accessibility and enable a couple of apps (synergy_server and Logitech gaming software). Prior to this change I was unable to control my other computers with synergy or use macros with my G11. I doubt this is a direct connection for you but the Accessibility options are new and might apply to some other app of yours.
Congrats on the update. I did my own update over the weekend and have been dealing with some of my own odd keyboard issues.
Here are a couple of things I needed to to:
- Remove old Logitech gaming software and upgrade. Prior to doing this I was having issues using my square and curly braces. Special keys often send esc-[ sequences in the VIM context so this might be relevant.
- Go into System Prefs:Security and Privacy:Privacy:Accessibility and enable a couple of apps (synergy_server and Logitech gaming software). Prior to this change I was unable to control my other computers with synergy or use macros with my G11. I doubt this is a direct connection for you but the Accessibility options are new and might apply to some other app of yours.
answered Feb 26 '14 at 13:04
Todd Pike
11
11
add a comment |Â
add a comment |Â
up vote
0
down vote
If you are working in .sql
files in vim
(you don't mention) this could help you. I just dealt with this the other day.
In file ~/.vimrc
let g:omni_sql_no_default_maps = 1
this particular issue is discussed here
If you're not experiencing this problem with .sql
files in vim
then I apologize, my only thought would be to verify the mapping within vim
when the problem occurs.
:map Ctrl V âÂÂ
when you lose your ability to use your arrow, do that command and see if the mapping disappeared. if it did, this gives you a place to start digging in.
add a comment |Â
up vote
0
down vote
If you are working in .sql
files in vim
(you don't mention) this could help you. I just dealt with this the other day.
In file ~/.vimrc
let g:omni_sql_no_default_maps = 1
this particular issue is discussed here
If you're not experiencing this problem with .sql
files in vim
then I apologize, my only thought would be to verify the mapping within vim
when the problem occurs.
:map Ctrl V âÂÂ
when you lose your ability to use your arrow, do that command and see if the mapping disappeared. if it did, this gives you a place to start digging in.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
If you are working in .sql
files in vim
(you don't mention) this could help you. I just dealt with this the other day.
In file ~/.vimrc
let g:omni_sql_no_default_maps = 1
this particular issue is discussed here
If you're not experiencing this problem with .sql
files in vim
then I apologize, my only thought would be to verify the mapping within vim
when the problem occurs.
:map Ctrl V âÂÂ
when you lose your ability to use your arrow, do that command and see if the mapping disappeared. if it did, this gives you a place to start digging in.
If you are working in .sql
files in vim
(you don't mention) this could help you. I just dealt with this the other day.
In file ~/.vimrc
let g:omni_sql_no_default_maps = 1
this particular issue is discussed here
If you're not experiencing this problem with .sql
files in vim
then I apologize, my only thought would be to verify the mapping within vim
when the problem occurs.
:map Ctrl V âÂÂ
when you lose your ability to use your arrow, do that command and see if the mapping disappeared. if it did, this gives you a place to start digging in.
edited Feb 26 '14 at 17:48
Abhijeet Kasurde
422316
422316
answered Feb 26 '14 at 17:12
driz
649
649
add a comment |Â
add a comment |Â
up vote
0
down vote
I had this problem in an SSH session and solved it by logging out then back in again:
exit
ssh ...
Thanks for weighing in. The selected answer has consistently worked for me though. Have you tried it?
â svidgen
48 secs ago
add a comment |Â
up vote
0
down vote
I had this problem in an SSH session and solved it by logging out then back in again:
exit
ssh ...
Thanks for weighing in. The selected answer has consistently worked for me though. Have you tried it?
â svidgen
48 secs ago
add a comment |Â
up vote
0
down vote
up vote
0
down vote
I had this problem in an SSH session and solved it by logging out then back in again:
exit
ssh ...
I had this problem in an SSH session and solved it by logging out then back in again:
exit
ssh ...
answered 5 mins ago
duhaime
1435
1435
Thanks for weighing in. The selected answer has consistently worked for me though. Have you tried it?
â svidgen
48 secs ago
add a comment |Â
Thanks for weighing in. The selected answer has consistently worked for me though. Have you tried it?
â svidgen
48 secs ago
Thanks for weighing in. The selected answer has consistently worked for me though. Have you tried it?
â svidgen
48 secs ago
Thanks for weighing in. The selected answer has consistently worked for me though. Have you tried it?
â svidgen
48 secs ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f116365%2farrow-keys-spontaneously-stop-working-in-vim%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
I also just realized there's an Apple-centric forum here that this question might be better suited for. So, if this is more likely a condition of OS X than
vim
, perhaps a mod could migrate this for me.â svidgen
Feb 22 '14 at 3:55
1
Reminds me of working on a "Prime" mainframe in college. The professor taught that you should never use the arrow keys in
vi
. Always use hjkl. That's where the "arrow" keys use to be on ancient hardware.â Red Cricket
Feb 22 '14 at 3:56
OK... But, the arrow keys should work. Regardless of whether your professor thinks I should use them. And I find them convenient at times. So, looking forward to see the solution.
â svidgen
Feb 22 '14 at 15:28
1
what happens when you insert the key literal into a buffer? go into insert mode, and press Ctrl+v, then an arrow key. Vim on my Mac shows the up arrow key as
^[OA
, down as^[OB
, right as^[OC
, and left as^[OD
. check before and after the problem presents itselfâ Nathan Wallace
Feb 26 '14 at 18:21
@NathanWallace not sure how I overlooked your question. I'll try that when I'm at my Mac next.
â svidgen
Mar 4 '14 at 4:53