Close popup menu on Esc: do not feed ^E for Esc

[blueyed]

complete_CTRL-E is different from Escape in the popup menu; Escape is
meant to close it, while CTRL-E will leave you in insert mode.

[artm]

What should I do to test the effect of this?

[blueyed]

Make the completion menu popup from insert mode, e.g. via C-X C-O for omni completion, then press Esc.
Insert mode should get ended then, but when using C-E (or Esc with autoclose), it will not leave insert mode.
See also "h: complete_CTRL-E".

[Townk]

Guys, this is on purpose. When you have the popup menu visible all the keys have a different behavior. If you do not want the C-E on popup menu, I'm pretty sure you can configure Autoclose to not behave like that. I'm away from my computer and I can't double check this.

--Thiago Alves
Computer Scientist

http://www.thiagoalves.com.br (http://www.thiagoalves.com.br/)

[email protected] (mailto:[email protected])

"Man's mind, once stretched by a new idea, never regain its original dimensions."
-Oliver Wendell Holmes

On Saturday, September 29, 2012 at 11:43 AM, Daniel Hahler wrote:

Make the completion menu popup from insert mode, e.g. via C-X C-O for omni completion, then press Esc.
Insert mode should get ended then, but when using C-E (or Esc with autoclose), it will not leave insert mode.
See also "h: complete_CTRL-E".

—
Reply to this email directly or view it on GitHub (#40 (comment)).

[rodolf0]

I'm having the same issue as blueyed and can confirm it's very annoying. Anyway, can override setting
let g:AutoClosePumvisible = {"ENTER": "<C-Y>", "ESC": "<ESC>"} in my .vimrc

[blueyed]

@Townk "Esc" closes the popup menu and leaves insert mode by default - I do not see why autoclose should change this behavior?!

[Townk]

Here we get to a delicate subject. Check it out:

When a popup menu appears on "any" application, what happens is that the
context of that application changes from wherever you were to the pop up
menu.

Unfortunately, vim doesn't handle this the way it should. The maps I choose
add handle this automatic context changing. For instance, when a popup menu
shows up, means you want to cancel that operation and get back to
where you were (C-E). If you press you're confirming that automatic
operation (C-Y) and so on.

I understand that many people don't like this configuration and that was
the reason I put the config options so you can change as you want.

Also I need to handle this because of all the map I do for the dot preserve.

On Sun, Sep 30, 2012 at 5:44 PM, Daniel Hahler [email protected]:

@Townk https://github.com/Townk "Esc" closes the popup menu and leaves
insert mode by default - I do not see why autoclose should change this
behavior?!

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/40#issuecomment-9018839.

Thiago Alves
Computer Scientist

http://www.thiagoalves.com.br

[email protected]

"Man's mind, once stretched by a new idea, never regain its original
dimensions."
-Oliver Wendell Holmes

[blueyed]

Well, you are changing Vim's default behavior by feeding C-e for Esc.
And changing defaults is likely to cause confusion and should be avoided.
Given that it's a configuration option I suggest that autoclose should ship the expected behavior, and you could override it locally in your vimrc.

The issue here is not only that Vim stays in insert mode, but that it first exits insert mode (after closing the popup) and then re-enters insert mode after a short delay (less than a second, but annoying).
(This might be related to some timeout for escape sequences)

I think that the default in Vim is feasible: Esc allows you to exit insert mode, also from inside a popup menu.

The main issue here is probably that after all, the popup can appear automatically (see NeoComplCache or autocomplpop) and that should not cause you to press Esc twice (after waiting ~1s in between).

[bentomas]

I agree with @Townk that the default Vim behavior is wrong and that it should A) leave you in insert mode when you press escape with a popup and B) hitting enter should select the current item and leave the popup.

(in fact, I was constantly thrown by the popup behavior until reading this thread, turns out I need to read the help more!)

But I also agree with @blueyed that the vim-autoclose plugin shouldn't change the default Vim behavior. vim-autoclose should use the existing mappings, and then another plugin or the user settings should change the popup settings. Basically, vim-autoclose should stick to automatically closing parenthesis and quotes and do nothing else. vim-autoclose changing popup settings is confusing and not what users expect (as evidenced by this conversation).

---

@Townk, you said:

Also I need to handle this because of all the map I do for the dot preserve.

Does this mean that the only way to use vim-autoclose AND get the "correct" popup behavior is through vim-autoclose? Or would it be possible to change vim-autoclose to fallback to the default esc and enter mappings? That seems like the best course of action. Then to fix the popup behavior, you could just do:

inoremap <silent> <expr> <ESC> (pumvisible() ? "\<C-E>" : "\<ESC>")
inoremap <silent> <expr> <CR> (pumvisible() ? "\<C-Y>" : "\<CR>")

[bentomas]

I figured out a fix that doesn't require having vim-autoclose be in charge of custom mappings for movement characters that are also popupmenu-keys. The issue was that vim-autoclose needs to remap all the movement keys to run the FlushBuffer function to get . re-do to work. And that gets tricky figuring out how to keep user defined mappings for those keys.

The fix is to store the old mapping in a plugin specific mapping, and then call it from our new mapping along with the FlushBuffer command.

After this, you can run the mappings from my previous comment to get the "correct" vim popup behavior. This allows us to remove all code related to mappings for pumvisible. I'll write up a pull request sometime soon with this fix.

[Zeta611]

Any updates on this issue?

[blueyed]

I (original reporter) am using https://github.com/Raimondi/delimitMate by now, unsubscribing.

[Zeta611]

@blueyed Thanks, I'll give it a try.