Skip to content
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

jump_to_def_tabnew collision with default vim window keybind #113

Open
Shadowsith opened this issue Jun 10, 2018 · 3 comments
Open

jump_to_def_tabnew collision with default vim window keybind #113

Shadowsith opened this issue Jun 10, 2018 · 3 comments

Comments

@Shadowsith
Copy link

Shadowsith commented Jun 10, 2018

You're default g:phpcomplete_mapping:'jump_to_def_tabnew': '<C-W><C-[>'colides with the standard window switching option in vim Ctrl+W+ArrowKeys.

If you work with multiple windows (e.g. NERDTree or splitscreen) it is very anyoing.

Can you change this to another default key mapping or write a warning to your readme that It could collide with standard vim key bindings?
I have changed that for myself but I use a lot of plugins and this took me a while to troubleshoot.

Thanks!

@Shadowsith Shadowsith changed the title jump_to_def_tabnew collission with default vim window keybind jump_to_def_tabnew collision with default vim window keybind Jun 10, 2018
@complex857
Copy link
Collaborator

I'm sorry to hear that you've had such a headache with the plugin.

I'm a bit confused here how come they actually in collision with that one. Shouldn't all ctrl+w sort of binding be an issue not just the tab one? I believe there're 3 in total now (split/vsplit/tab).

I don't have an access to a windows machine at the moment, but in my memories the ctrl+w was working as expected. The reason the <C-w> was picked because most of the window related command are similar to these (like opening a split/vsplit).

From what I remember the default windows installs source this config file to handle differences, but the only window related binding in it I can see <C-Tab>, the <C-W><Left> as far as I know universal as a binding.

Can you confirm me that it's only the tab binding that's the issue?

@Shadowsith
Copy link
Author

Thanks for your answer.
It was not such a big problem but it was a bit of work to get the reason of the issue.

I have tested it again with default phpcomplete settings and all +Arrowkeys opens a new tab from a php file. Of course it's not a real technical issue and I can not say how many users could have a problem with this default binding but I mostly use the keyboard arrows and not the vim specific ones in the normal mode (h,j,k,l) to change windows.

I can't say if there is a difference on windows because I only work on Linux with vim.

In my settings I have changed the bindings from <C-w> to <C-d><'Arrows'> and it makes no problems anymore.

I think a vew words on the README that the default settings could be a problem if someone prefers to change windows in vim with <C-w> and arrow keys would be enough.

@pmaziere
Copy link

pmaziere commented Jul 3, 2018

I also got annoyed by this issue, so I looked into it to understand further.

it comes from the fact that arrow keys send the following sequence to the terminal:
Up: <C-[>A
Down: <C-[>B
Right: <C-[>D
Left: <C-[>C

Since the default vim window keybinding sequences start by <C-W>, when phpcomplete is active, moving the focus to the window below the current one results in sending <C-W><C-[>B which is stolen by phpcomplete to create a new tab and then insert a B.

I noticed that when hitting <C-W>, waiting 2 seconds, then hitting arrow Down, phpcomplete does not steal input for itself.
I don't know what should be the appropriate fix, but I guess that it should either be a change in the default 'jump_to_def_tabnew' keybinding, or make something of the "race-condition-like" event I described above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants