Key binding conflict with lisp-paredit

[alza-bitz]

The ctrl-alt-, xyz and ctrl-alt-< xyz bindings in proto-repl appear to conflict with the ctrl-alt-, and ctrl-alt-< bindings in lisp-paredit (used for lisp-paredit:barf-forwards and lisp-paredit:slurp-backwards).

As such, extra work is required by the developer to resolve the conflict by manually overriding the key bindings in keymap.cson.

It would be great if proto-repl could use base key bindings other than ctrl-alt-, and ctrl-alt-<, so as not to conflict with lisp-paredit.

[carocad]

I don't think there is much here to be done on the proto-repl side. This is a persistent and particularly painful problem of atom itself: https://discuss.atom.io/t/key-binding-hell/12075/14

I think that finding THE keybinding combination that works for everybody is just impossible

[jasongilman]

I've tried a few different key bindings in proto repl over the last year and I'm hesitant to switch it again. Each time I do this it requires all the users to learn the new keybindings. I know lisp paredit is a package that many developers are likely to use but my guess is that most people would use parinfer. I'm closing this issue though I welcome alternative suggestions and ideas.

[kwladyka]

👍

Paredit is much better then parinfer for experienced users in my opinion and probably many Clojure users use paredit. I don't know any statistics, it is just my wish :) Still it is confilct by default for most of users and it should be solve by default configuration. It is not conflict with some strange third party package, but with really default package for Clojure Developers.

I don't want suggest any shortcuts, because i am new atom editor user and don't know too many packages bindings. Just wanted give +1 to not turn back from this problem, because it wouldn't disappear :) As long it exist i suggest add info about that to readme to change shortcuts manually if somebody use lisp-paredit - it will save time to find what is wrong in google for many people.

From other side all atom packages are not mature yet and find the right solution can be hard today. Maybe we can share here suggestions what is the best shortcuts configuration without conflicts? Probably we can find something.

[alza-bitz]

In the end, to resolve the conflict I decided to use a custom key binding for proto-repl, in which I map ,/< to ;/: respectively.

I chose this alternate key since:

• It's near to the ,/< key on a lot of keyboard layouts
• It's not mapped to any core Atom key bindings.

I created an Ansible playbook which sets up this alternate mapping.

[jasongilman]

@kwladyka Thanks for the well reasoned argument. @alzadude Thanks for the suggestion. I think this issue could be resolved by programmatically setting the keybindings. There could be a setting that specifies which prefix to use for the keybindings. I think I've seen other packages use that approach.

[allentiak]

What about using ctrl-alt-; (semicolon) as the starting sequence for all (of most) keybindings, instead of ctrl-alt-, (comma)? This would also have the advantage of being a little bit more ergonomic for Dvorak/Colemak layout users (and would not mean a big difference for "standard" QWERTY layout users).

[jasongilman]

ctrl-alt-; seems like a reasonable choice. I don't see any conflicts with the packages I have installed. Note that you can easily take the keybindings in proto repl and create your own. You can copy the contents of this file into your user keybindings, customize the keys, and disable the proto repl default keybindings in the settings. That's not to say it's not worth fixing this particular issue.