Keyboard layout seems to not be respected.

[mcourteaux]

I tried it out for the first time, and it seems that I cannot control Focus if I'm on AZERTY keyboard layout. Also, after changing to QWERTY, I was following the default config file, and tried Ctrl-Shift-, to duplicate the editor, but that didn't work. Only Ctrl-, worked.

[ileonte]

Are you running on X11 or Wayland?

[mcourteaux]

I'm running on Linux with X11. You can try this by changing the keyboard layout to mine: setxkbmap -layout be, if you'd be on Linux to test this.

Then trying to type a forward slash (/) in the "Navigate to File" popup, doesn't work. Funnily enough it does work in the "Open by Name" popup.

[focus-editor]

Then trying to type a forward slash (/) in the "Navigate to File" popup, doesn't work. Funnily enough it does work in the "Open by Name" popup.

The forward slash has a different meaning in the Navigate to File dialog - it enters the topmost directory, so it's intended. We could reconsider this behaviour if people find it confusing.

[mcourteaux]

The strange thing is that it does type the / when my keyboard is in qwerty.

[ileonte]

I've been able to reproduce the problem on my end, I'll look into fixing it as soon as possible.

[ileonte]

This should be fixed in 0.1.6. I will close this issue once @mcourteaux confirms that the fix works as expected.

[mcourteaux]

I just pulled and recompiled, but none of the behavior changed. I tried all the things I reported on again, and nothing changed.

[ileonte]

Just to make sure I'm testing the same thing - is this the layout you are trying to use? Also - what WM/DE are you using?

[mcourteaux]

Yes, that exact layout. So the slash is two buttons left of the Right Shift. Trying to do Ctrl-Shift-, might get confused for Ctrl-Shift-?, as the shift brings the , to a ?.

I'm on X11 with i3.

[ileonte]

Ok, I think I understand what's going on. There are two separate issues at play here:

1. when you opened this issue originally keyboard layouts were completely ignored in the editor (pressing the 4 keys immediately right of the Tab key with the Belgian layout activated was interpreted as qwer instead of azer for example). This is what should now be fixed. As an added bonus, key composition should also now work properly (for example, when using the Belgian layout, pressing AltGr-- followed by t will now give you ţ).

2. there is a separate issue in the Linux build that happens regardless of the active layout - and that is that Shift-<key> combinations are reported as {shift_pressed: true, key: "shifted-up-key"} (for example if you press Shift-= it is reported as {shift_pressed: true, key: "+"}). The problem you reported in the 'navigate to file' dialog is exactly this - there / is bound to the open_directory action, but since to make / you have to press Shift-: this will never match what the editor expects. To verify that this is indeed the case open the config file, search for the [open file dialog] section and change

   /  open_directory

   to

   Shift-/  open_directory

   Likewise, Ctrl-Shift-, will never match anything as the event that is reported is {shift_pressed: true, ctrl_pressed: true, key: "?"} (in the config file you would have to specify the combination as Ctrl-Shift-? for it to match).

   I am still unsure how to fix this second issue. To be honest, I'm not even convinced it is an issue - for example in KDE if I try to bind Ctrl-Shit-= as a shortcut it is interpreted as Ctrl-+, so apparently we're not the only ones confused about the situation.

   Any suggestions welcome.

[ileonte]

I'm going to close this, as far as I'm concerned the behavior I described above makes sense. If anyone disagrees we can either reopen this issue or make a new one.

[mcourteaux]

I only took the time now to think, as you closed it. Sorry for that! :) Your analysis seems really on point!

It is indeed a confusion situation, some keyboard shortcuts might want to use + for zooming. For me, + is under shifted-up =. So then the question becomes, do you want to report the "control zoom-in" shortcut as Ctrl-+ or as Ctrl-Shift-=? From my experience, I like reading the first, as it describes what it does better, and I have no problem automatically adding that shift when I see the +. So for the Ctrl-+ example, the reported {shift_pressed: true, key: "+"} is fine, as long as you ignore the shift.

The problem arises when you want to do the opposite. Define a shortcut that explicitly does NOT have shift pressed, like Ctrl-+ without Shift, because you have another shortcut Ctrl-Shift-+ that does something else. This is literally impossible on a Belgian keyboard without resorting to the numpad. Meanwhile, on QWERTY, it is possible as + is on the base layer.

So, after writing this down, I think keyboard shortcuts should ONLY rely on using shift for predictable shifted characters. This would mean: ONLY the unaccented alphabetic characters A through Z. All signs and punctuation is keyboard layout dependent, and would require shifts to get them at some layouts and on some not. Thus, to conclude, I think a safe rule is that if you design keyboard shortcuts:

• only letters, escape, tab, backspace, enter pageup/down, home/end, arrow keys, and Fn-keys (although I would avoid Fn-keys because of macOS and media-keys being under them often) can use shift, like Ctrl-Shift-v, while relying on keycodes.
• all punctuation/signs/symbols cannot use shift, and should use the meaningful textual character represented by that keypress, i.e., the "shifted-up" character, or the altgr-ed character. This means you cannot rely on keycodes nor scancodes.

I like this, and will try this strategy in my program.

[ileonte]

I don't think what you describe works. For example, on the Czech keyboard layout + is "unshifted" while 1 is Shift-+ (basically the inverse of the situation you outline above).

[mcourteaux]

Why would this be a problem if you stick to the rule? The rule I outlined prohibits the use of Shift for all symbols/signs (including digits). So Shift-+ and Shift-1 would be both prohibited. So for + and 1, only combinations with Ctrl would be allowed. So, Ctrl-+ is clear, and Ctrl-1 on Czech keyboard would require you to physically press Ctrl-Shift-+.

[ileonte]

It wasn't clear to me that you included digits in "symbols" (to my mind they are just "letters"). After 0.3.0 is released I will try experimenting with this idea (it might impact the other platforms as well and I don't want to potentially mess it up for the release).

[focus-editor]

ONLY the unaccented alphabetic characters A through Z

What about the F keys?

[mcourteaux]

I think F-keys (function keys, fn-keys) are fine to use, but would avoid combining them with modifiers, as people will already need to press some special button to make them NOT be the media-keys (I have stuff like music controls (play/pause, next, previous), screen brightness, keyboard illumination, volume buttons) on the Fn-keys. I personally prefer to keep those media-actions under the Fn-modifier, but I know that many people have it backwards (by default on Apple devices): the media-actions are accessible by pressing the F-keys without modifers, and only with the modifier it becomes the F-key. So people having to already press one modifier to get it to them to be Fn-keys instead of media keys, is gonna be troublesome if you combine that another modifier like Ctrl or Shift. On many keyboards, the Fn-key is some right of the spacebar, while the Shift/Ctrl modifiers are on the left: combining those -- while possible -- is going to be awkward I think.

[focus-editor]

Do I understand correctly that you suggest to just prohibit the use of modifiers for those keys?

If yes, then this solution is way worse than the problem, because we would be constantly asked why e.g. people can't bind Release Run to Ctrl-F9

[mcourteaux]

You could definitely allow them to bind it themselves, but I guess I would avoid trying to use those as the default configuration, because of different behavior across keyboards/OS's.

I just tested this on my macOS laptop, and the media-keys do not get reported in an application when pressed with Ctrl or Shift or Alt (i.e. "Option"). So media-keys are always media-keys unless you press the Fn button on the Apple keyboard, after which you can start combining it with other modifier keys.

The Fn-key is (contrary to what I thought) on the left of the spacebar instead of right, so making keyboard shortcuts with them in combination with modifiers is not as much of a hassle to type them as I was expecting. (I think I was confusing it with the AltGr key)

[Ikxi1]

Hey I'm also having issues with the German QWERTZ layout where ÄÖÜ for example aren't recognized in the keymap. If I change my windows lazout to US QWERTY and then I can have ; ' [ (which are at the same position as ÄÖÜ) for the kezmaps, but when I switch back to DE lazout it also doesn|t work.