Townk / vim-autoclose

This plugin for Vim enable an auto-close chars feature for you. For instance if you type an '(', ``autoclose`` will automatically insert a ')' and put the cursor between than.
http://townk.github.com/vim-autoclose/
503 stars 66 forks source link

Insert mode arrow keys #3

Closed domidimi closed 13 years ago

domidimi commented 14 years ago

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 commented 14 years ago

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 commented 14 years ago

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

lennartkoopmann commented 14 years ago

same here

skyeagle commented 13 years ago

same issue

hyperbolist commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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

Townk commented 13 years ago

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

Townk commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

Please, do this:

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

What is the result?

rosenfeld commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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:

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

Any idea?

Townk commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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!