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

Keys that autopair use should be able to perform their original actions after this plugin loaded #14

Open
kutsan opened this issue Oct 5, 2017 · 10 comments

Comments

@kutsan
Copy link

kutsan commented Oct 5, 2017

zsh-autopair overrides some existing keys like ", ' and such. Those keys can't be used with their original behaviour after zsh-autopair sourced if users have existing widgets for that.

Recently, owner of this plugin added two fallback for ^? (Backspace) and (Space) keys but apparently more general solution needed.

@hlissner
Copy link
Owner

hlissner commented Oct 5, 2017

Alright, a more generalized solution is in place. Let me know if it gives you any trouble.

@kutsan
Copy link
Author

kutsan commented Oct 6, 2017

Commit a01f074 introducing a new error. It breaks the zsh-syntax-highlighting plugin and its some features are not working correctly. Everything is okay under b486f0d.

By the way, your solution isn't working even if we ignore this error. I write bindkey -M viins '^?' vi-forward-char to my .zshrc for testing purposes, before sourcing zsh-autopair. It didn't work out.

hlissner added a commit that referenced this issue Oct 6, 2017
@hlissner
Copy link
Owner

hlissner commented Oct 6, 2017

I found the problem and pushed a fix. Let me know if it gives you trouble!

@hlissner hlissner added the bug label Oct 6, 2017
@kutsan
Copy link
Author

kutsan commented Oct 6, 2017

Well, I have still the same problem. I can confirm I am on e73053d.

@z0rc
Copy link

z0rc commented Oct 6, 2017

I don't want to derail the plugin development, but may the features be developed in separate branches, rather then in master?

@kutsan
Copy link
Author

kutsan commented Oct 6, 2017

@z0rc I agree with that.

hlissner added a commit that referenced this issue Oct 6, 2017
hlissner added a commit that referenced this issue Oct 6, 2017
@hlissner
Copy link
Owner

hlissner commented Oct 6, 2017

Agreed. Sorry, should've done that from the start. I've effectively reset master to b0a995a and moved this feature to the widget-fallback branch (which I'll put up soon).

@kutsan
Copy link
Author

kutsan commented Oct 6, 2017

Also, I wouldn't force push if I were you. Now, probably someone dealing with their weird looking git history and wondering what went wrong. There is safe alternative for that.

@hlissner
Copy link
Owner

hlissner commented Oct 6, 2017

I apologize for any trouble, but I understand the pitfalls. Also, --force-with-lease's selling point is it prevents overwriting "unpulled" commits on the remote. It wouldn't have made a difference here.

In any case, your feature is now in widget-fallbacks, could you try it out? If it doesn't work, would you also mind trying develop too? I haven't had much luck reproducing your past issues across several computers and docker images; I'd like to be certain.

@kutsan
Copy link
Author

kutsan commented Oct 7, 2017

Okay here's my report with this lines in my config.

bindkey -M viins '^?' backward-kill-word
source "$ZDOTDIR/plugins/zsh-autopair/autopair.zsh"

In develop branch, everything is like that. My binding works but there is nothing left of autopair. Backspace always deletes word backwards. Whereas it should have deleted the last pair if there is one.

In widget-fallbacks branch, everything still looks the same like I said above. It breaks zsh-syntax-highlighting and binding doesn't work at all. autopair and its other features works though.

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

No branches or pull requests

3 participants