Insert mode arrow keys

[domidimi]

Code on line 413 : " Fix the re-do feature: inoremap =FlushBuffer() breaks the arrow keys in insert mode when using vim in a terminal. Don't know if it is a vim bug. Maybe take a look here: http://groups.google.com/group/vim_dev/browse_thread/thread/f74f0606cc64aee6/1f378bd49359304d?lnk=gst&q=arrow#1f378bd49359304d

[rosenfeld]

I found that the commit 078e1bef has broken the arrow keys for me on insert mode in terminal vim (doesn't happen on gvim).

[ku1ik]

The same for me, console vim's arrow keys are broken, but in gvim it is fine.

[lennartkoopmann]

same here

[skyeagle]

same issue

[hyperbolist]

I too experience this.

The interwebs seemed to think this would help in my .vimrc:

if ($TERM == "screen")
  set term=linux
endif

and it did. Until things went strange and I had to reset. YMMV.

[Townk]

I don't think this is an Autoclose issue, maybe it's has to do with some mappings that I put there. I'll look into this tonight.

-Thiago

[rosenfeld]

As I said, this is certainly an Autoclose issue and it was introduced on commit #078e1bef.

[Townk]

Yep, I already know which maps caused the problem. Tonight I'll check how to prevent this without loosing functionality.

[Townk]

Sorry to tell you rosenfeld but I could get it working without any modification on the plugin!

The problem was happen to me because I had set my $TERM variable to "mostlike". I tried with "vt100", "xterm", "xterm-color", "vt360" and all those values produced the same problem (even without the plugin).

BUT, when I unset the variable or set it to "linux", then everything worked as expected!

Can you try this and tell me if worked for you?

If not, can you describe in detail what happens when you press on insert mode with vim on terminal?

Thanks, Thiago

[Townk]

Also I found a bunch of docs reporting the issue with the terminal vim. My personal workaround for this was to set on my .vimrc file some maps to my "escaped arrow keys", like this:

imap ^[OA pumvisible() ? "" : "k" imap ^[OB pumvisible() ? "" : "j" imap ^[OC l imap ^[OD h

Notice that ^[OA I got on the terminal vim pressing "+V" than "down arrow".

[rosenfeld]

Hi Thiago, what I'm saying is that I can use your plugin without any issues if I checkout d1dbc6abcf8aedd47422c0d516817f221e44424c, independently from what TERM is set to (it defaults to xterm in Debian). With master, even if I set it to 'linux' I still have problems with the Up key, but it is another one.

So, what I'm saying is that anyone using Debian or Ubuntu will have problems by default when trying to use your plugin. If you prefer we can also discuss this in Portuguese.

If your plugin depend on the mappings above to work correctly in terminal vim, so I think you should map them inside the plugin and not on the user vimrc. But anyway, even with the above mappings I couldn't get it to work with master.

[rosenfeld]

Commenting the line below over master seems to fix the problem for me:

"inoremap =FlushBuffer()

Also, do note that I'm using several other plugins and not just yours, so maybe this line is conflicting with other plugins in terminal mode: https://github.com/rosenfeld/vimfiles

[Townk]

Please, do this:

Comment this line; Restart vim on terminal; issue on normal mode: :verb imap

What is the result?

[rosenfeld]

When I comment the line, vim says: "Nenhuma associação encontrada" (no association found)

When I uncomment:

"Definido pela última vez em .../autoclose.vim" (last defined on)

[rosenfeld]

Sorry, I've just seen Github has modified the message about the line I've commented. This is the line:

"inoremap <buffer> <silent> <Esc>        <C-R>=<SID>FlushBuffer()<CR><Esc>  

[Townk]

Ok, so here is what I see:

There is no way to the mapping affect the arrow keys, unless your terminal is issuing an escaped character when you press the arrows.

Another questions:

Are you using the terminal on the console mode or in a graphical terminal application like gnome-terminal?

Can you try on both?

I don't have a linux installed here, but I'll try to get a VM with it to verify what you're saying and try to reproduce it.

[rosenfeld]

From what I've observed, vim behaves the same way both in console mode and in konsole (graphical terminal). The only difference is that in console mode, TERM is set to 'linux', while in graphical terminal it is set to 'xterm'. If I set TERM to 'linux' in graphical terminal I get the same behavior, which is:

• the first time I move down it does nothing. After that it works without problems.
• if I move up in the first time in insert-mode (quiting vim and launching it again), it shows the message below, also does nothing (like when I press down), and after that everything works great:

"E37: Alterações não foram gravadas (adicione ! para forcar)" (changes were not saved)

Any idea?

[Townk]

Ok, I just installed a Linux on my VM (Ubuntu 10.10).

When I play with vim on terminal without any plugin it works as expected and when I add my plugin it fails on arrow keys as you reported.

The failing behavior I get is this:

On insert mode, I press and I get a new line above the one I'm with the cursor in and the letter A on he new line.

Why this happens? Here is the answer:

The terminal application upon an up arrow send the following sequence to term: OA

If you don't have anything mapped to on vim, this will work as expected because the sent sequence is translated to an in the end by the terminal.

When you map the key to anything on vim, the first character is intercepted by vim and the next chars are send normally, so the result is:

A new line above where you are: O The 'A' char on the new line: A

Unfortunately there is no known solution for this problem if you have to map the key.

So, here is WHY I have to map the key on Autoclose plugin:

To preserve the undo tree and to add all completion into the ". register I need to "flush" all completion buffer when user exists the insert mode. I tried to do it on the autocommand InsertLeave this trigger is called "after" the mode was changed, therefore I cannot insert anything on buffer on this place. So the only solution was to map the key.

Notice that the ability to have an autocompletion inserted on your text multiple times just pressing the "." on normal mode is not a feature everyone needs, so I'm thinking in add some kind of option to user explicit enable or disable this feature, this way you could just say you don't want it and Autocomplete will not map the and other keys preventing those problems on terminal to happen.

I'll get back to you when I think about this a little better.

[rosenfeld]

You could add this to the Troubleshooting section of your documentation, stating that this feature should be disabled if the user is experiencing this kind of problem until we can get a cleaner solution. Maybe there's another way of capturing the "before leaving insert" event.

[Townk]

Ok guys, this is it.

I just commit a "partial" solution for this. I added a config variable to plugin called g:AutoClosePreservDotReg that when set to 0 it'll prevent AutoClose to to flush the completion characters into the ". register and mapping the flushing keys for this (esc, up, down, left and right).

So, if you have seen this kind of bug on vim on a terminal you can add the following on your vimrc:

if !has("gui_running") let g:AutoClosePreservDotReg = 0 endif

This should prevent plugin from mapping the key which causes all the trouble.

So, I'll close this defect and put this notes on the documentation. Please, test it if you can!

Thanks for all the help, Thiago

[rosenfeld]

Thank you very much! It is working great with the settings but the only problem is that this option is not documented neither in doc/ nor in README.

[Townk]

I know, the next step before release this version on vim site is to update the documentation but since this is a huge change I'll do only on the weekend.

And just to let you know I also added an option for those who wants to tweek how the "Flush keys" behave when the popup menu is being shown. I'll let you know when the doc is updated and you can see how this works.

[rosenfeld]

Actually, I've edited my message because I've retested and the menu problem doesn't seem to occur in graphical vim anymore. So I don't know if this "tweek" is really necessary. You probably received my first message by e-mail and not the final edited one...

[Townk]

Yes, this was exactly what happened :)

Anyway, the tweak is necessary and you'll see why on documentation :). Let's hope I can finish it by Sunday!