Suggested non-vim bindings in README problematic for some environments?

[sogaiu]

In at least some Linux distributions, the suggested non-vim bindings are problematic.

All of them start with control comma, but IIUC in a default installation of Atom (at least in the 1.39.x series), this sequence will lead to the equivalent of Edit -> Preferences.

The conflict arose recently when suggesting to someone to try Chlorine. I had worked around it before by using control semicolon, but had forgotten this :)

I don't know if using control semicolon is better for other platforms, but if it isn't, perhaps it's possible to come up with an alternative that works all around, or at least mention in the docs that there might be issues with the suggestions.

Another alternative might be to mention the keymap-control plugin: https://atom.io/packages/keymap-control

After Atom starts, Keymap Control looks inside your keymap.cson file for any keybindings that conflict with keybindings from other packages and automatically unbinds them, removing the conflicts which can prevent your new keybindings from working.

This can remove keybindings from Atom's core just as easily as from 3rd party packages. Any keybindings you set in your keymap.cson file will always take precedence, so you can concentrate on setting the keybindings you want, instead of why they don't work.

I've only briefly tested it, but it appears to work as advertised so far. For reference, I found it via:

atom/atom-keymap#110

[seancorfield]

This is true on Windows too. If you are too slow to press the full Chlorine key binding, i.e., you pause between the ctl-, and the follow-on key, then the Settings page pops up. That's annoying at first but I quickly got used to it and I almost never trigger the Settings page by accident now... but keymap-control sounds useful to mention.

[sogaiu]

Interesting about the speed of input -- I had not noticed that kind of thing before. Will keep my eye out for it.

I tried a number of times to enter one of the Chlorine key sequences as fast as I could manage in my current non-Windows environment. I keep getting the settings though.

Perhaps it depends on the OS? With particular fingers poised over the appropriate keys (a non-typical arrangement to optimize for speed), I doubt one could get a whole lot faster at entering the key sequence.

[seancorfield]

Maybe the speed thing is just Windows? And on Linux it always shows settings?

[sogaiu]

May be so.

The Windows environment I have access to at the moment is over the network via RDP (though on a LAN). At least in that situation, testing the key sequence kept yielding the settings.

Perhaps with a "direct" (not over-the-network) setup there would be different results.

[mauricioszabo]

Well, I think these were the keymaps for some other libs that evaluate code. That was one of the reasons I don't add any keymap on Chlorine, because almost any keybinding will conflict with something on some platform...

@sogaiu do you suggest something else? Maybe add some info on the README, and suggest alternatives just below?

[sogaiu]

@mauricioszabo Yes.

I suggest:

1. Modify the leading text to:

This package does not register any keybindings to avoid keybinding conflict issues. You can define whatever you want via keymap.cson. The following have worked for some people:

2. Choose one of the following:

a. If the set of keybindings where each one starts with control comma are to be left there, then I think it would be better to state that it is known to not work that well in various Linux distributions and in some circumstances, Windows, and therefore, to choose something other than comma. (Another set of bindings that doesn't use the comma could also be listed as well.)

b. Change the current control-comma-using suggestion to not use the comma. I know that control followed by semi-colon (as the prefix) works for some Linux distributions and Windows. I just tested on a mac mini and it appears to work there too.

I don't have any attachment to semi-colon apart from the fact that it appears to work better than the comma for the 3 platforms. If somehow semi-colon is problematic, perhaps we can consider another alternative? I just think that keeping the comma there when it is known not to work for 2 out of the 3 platforms isn't nice to new-comers, and it also means it's more work for experienced people walking folks through initially :)

I think b. is simpler than a. and it takes less space, but there may be other factors (e.g. muscle memory of existing users, possibly conflicts with existing materials, etc.).

In any case, I am willing to provide a PR.

[mauricioszabo]

I think the option b is better too :)

Great, if you can provide a PR I'll gladly review and merge as soon as possible :)

[sogaiu]

Thanks!

[uniqss]

Thanks very very much!