Keybindings with [ or ] do not work as expected on azerty layout

[solsticedhiver]

Prerequisites

• Can you reproduce the problem in safe mode?
• Are you running the latest version of Atom?
• Did you check the debugging guide?
• Did you check the FAQs on Discuss?
• Are you reporting to the correct repository?
• Did you perform a cursory search to see if your bug or enhancement is already reported?

Description

Keybinding with [ or ] (and{ or }) do not work as expected on azerty layout. On the azerty (french) layout, one has to use AltGr to get a [ or ] or { or }. But keybinding like ctrl-] or ctrl-alt-] do not work.

A relative issue is keybinding like ctrl-/ and ctrl-k ctrl-0 do not work with the shift key down like it is needed on azerty fr layout to use to get a / or a number. (fixed in beta)

Steps to Reproduce

1. Try to use a keybinding with {,[,],}
2. Fails to see it work

ctrl-alt-] fold one level instead of unfolding
ctrl-alt-[ does nothing
ctrl-] outdent (desindent) instead of indenting
ctrl-[ does nothing

(this 2 ones work as expected on beta)
ctrl-k ctrl-number does work but without shift key has it should (as in qwerty layout)
ctrl-/ works but without shift key (as in qwerty aloyut)

Another issue is that the keybinding the the menu (Edit > Folding and Edit > Lines) do not match the ones listing in Settings > Keybindings
In settings:
ctrl-alt-{ : fold all
ctrl-alt-} unfold all

in menu:
maj-ctrl-alt-] unfold all
maj-ctrl-alt-[: fold all

while maj-] is } on a qwerty keyboard it is not true on azerty layout

Versions

It happens on atom 1.11.2 and atom 1.12-0 beta6 too on ubuntu 16.10

[Ben3eeE]

Atom 1.12.0-beta6 comes with a public custom keystroke resolver API. Using that you should be able to work around these problems.

[Ben3eeE]

Hey, we have made many improvements to keystroke resolution since this report. Can you still reproduce this behavior on the latest version of Atom 1.12.4?

[solsticedhiver]

half of them are working: the ones with ] are wokring but not the one with [

[Ben3eeE]

Hi,

If I understand your report correctly you have something bound to Ctrl-Alt-[ which requires you to press (on Azerty FR) Ctrl-Alt-AltGr-^ and this works for ] but not for [. Can you please write a list of keys which combinations that don't work for you in the latest version of Atom? Just so I can confirm. Thank you.

[solsticedhiver]

oops sorry it's still the same as the first 4 lines of my first post.

ctrl-alt-] fold one level instead of unfolding (ctrl-alt-altGr--)
ctrl-alt-[ does nothing (ctrl-alt-altGr-5)
ctrl-] outdent (un-indent) instead of indenting (ctrl-altGr--)
ctrl-[ does nothing (ctrl-altGr-5)

[lee-dohm]

@Ben3eeE do we still need more information here?

@solsticedhiver is this still happening on Atom v1.12.7 or later?

[Ben3eeE]

@lee-dohm No we don't need more information. Thanks for the reminder 🙂

This is because of the these lines where we fall back to the non AltGraph character when any modifier besides AltGraph is depressed during the keystroke on Linux.

This was introduced in atom/atom-keymap#152 and briefly discussed in atom/atom-keymap#193. I am leaning towards removing these lines right now but I am also unsure about the exact reason for them being introduced so I can't make that decision.

@nathansobo Can you give some insight to why this case was added? Can we safely remove it? Currently it causes problems because we have to revert to retrieving information from X11 which causes problems on some Linux systems (E.g. Gnome depending on order of layouts). Maybe AltGraph should be a separate modifier on Linux in the future but just removing this case seems like an enhancement right now (Without me having any context).

[nathansobo]

@Ben3eeE The logic in question was introduced in atom/atom-keymap#152. The main purpose of that PR was to introduce a workaround for a bug where Chrome was reporting the wrong key values when the ctrl modifier was used on Linux. Since that PR introduced native keymap generation for Linux as part of the work around, I decided to add logic for falling back to the non-alt-graph character variant when combined with other modifiers in order to be consistent with our behavior on Mac and Windows.

On Mac and Windows, the behavior is more essential because AltGraph isn't a distinct key. On Mac, there is no such thing as a dedicated AltGraph key and on Windows it is conflated with ctrl-alt. Not falling back on those platforms would mean you couldn't use modifiers like ctrl-alt-shift- etc.

On Linux, as far as I understand, there's a distinction between Alt and AltGraph and no conflation with ctrl-alt-. This means that the normal Alt can be combined with other modifiers if that's what the user intends. In light of our issues computing the correct keymap, I think removing the fallback logic is the correct course of action.

@Ben3eeE Thanks for your diligence on this issue. I also really appreciate the clear context you provided with your @-mention, your clearly worded question and explicit proposal for action. That made it really easy for me to jump in and help out here.

[nathansobo]

Another solution would be to only fall back to the original value of the current key is non-ASCII, which we do on the other platforms. But perhaps in light of our issues computing the native keymap just removing the logic entirely is still better.

This issue raises some questions for me though regarding the reachability of certain bindings on layouts like AZERTY for Mac and Windows... How does one type ctrl-] on AZERTY layout on Windows? AltGraph is indistinguishable from ctrl-alt, so there's no way of knowing if you want the ctrl- as part of the modifier or you were just tying it to access ]. On the Mac it just becomes impossible to bind things like alt-] on such layouts. I'm not sure there's a better solution than those users just changing their bindings.

[Ben3eeE]

@nathansobo

How does one type ctrl-] on AZERTY layout on Windows?

Swedish layout has the same problem. For example ] is written using altgraph-9 or ctrl-alt-9 meaning that some key mappings are not accessible with the default configuration on Windows. On Linux, after removing the fallback, these should be accessible although some of them will require a ridiculous amount of modifiers, ctrl-alt-shift-altgraph-8 for editor:fold-selection.

Using a Swedish keyboard layout the following keys require altgraph to write: @£$€{[]}\~|

I believe that the key mappings in atom/atom that are not accessible on Swedish layout on Windows are:

'ctrl-]': 'editor:indent-selected-rows'
'ctrl-[': 'editor:outdent-selected-rows'
'ctrl-alt-[': 'editor:fold-current-row'
'ctrl-alt-]': 'editor:unfold-current-row'
'ctrl-alt-{': 'editor:fold-all'
'ctrl-alt-}': 'editor:unfold-all'
'ctrl-alt-shift-[': 'editor:fold-selection'

I don't use folding and editor:indent-selected-rows, editor:outdent-selected-rows are both accessible on the tab key so it has never been an issue for me.

[nathansobo]

So, we're still falling back to the non-alt-graph character when modifiers other than alt-graph are used. We could prevent this behavior when the alt-graph character is in the ASCII range and get closer, but there's still a problem on Mac and Windows for bindings that involve a character accessed via alt-graph and one of the modifiers involved in expressing the "alt graph" modifier (alt on macOS and ctrl/alt on Windows).

If you need to use a modifier to access a character, should that modifier be included in the keystroke string for that keystroke? For example, if you have to type ctrl-alt-' to get [ on a given layout, should we resolve that binding to ctrl-alt-[ or [? It seems like the modifier should be "consumed" in the process of using the modifier to access the alt-graph variant of the key.

I'm honestly not sure there's a single solution that will make everyone on every layout happy for this problem. Does anyone know of any precedent in other systems for addressing this ambiguity?

[solsticedhiver]

I am using Atom 1.23.1 now and I still see problem wit those key bindings. They are not exactly the same as reported ealier but for example, I can't fold or unfold with he keyboard because ctrl-alt-[ or ] do not work.

but ctrl-atl-" reported as ctrl-alt-dead (some dead key) by key-binding-relsolver fold one level
I did try all key combination but you got the idea. This is not working (at all)

[lee-dohm]

@solsticedhiver I think @nathansobo's comment directly above still stands. Specifically:

there's still a problem on Mac and Windows for bindings that involve a character accessed via alt-graph and one of the modifiers involved in expressing the "alt graph" modifier (alt on macOS and ctrl/alt on Windows).

I'd have to double-check with the devs, but I don't believe our keybinding system is capable of distinguishing between Ctrl+Alt and AltGr. If you or someone else wants to dig in to suggest a code change that could resolve that, I'm sure that we would take a look at it. Right now though, I don't think that the maintainer team is going to be investigating further soon.

[solsticedhiver]

ok. I did not read that comment. I am on Linux, though with an azerty (French) layout.

Aynway, I am using vim-mode-plus and ex-mode now, so the keybindings are easier and working now (zo, zc, zM etc ...) \o/

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!