Swedish Layout: Both Physical Hotkeys `⌘ + <` and `⌘ + ,` trigger the same command on MacOS

Steps to reproduce

Go to Hotkey settings and try to register ⌘ + < as a hotkey.

Expected result

⌘ + < is registered as a hotkey for the selected command.

Actual result

⌘ +, is registered as a hotkey for the selected command.

see screencast:

Environment

SYSTEM INFO:
Obsidian version: v1.1.16
Installer version: v0.15.9
Operating system: Darwin Kernel Version 22.3.0: Mon Jan 30 20:39:35 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8103 22.3.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: Minimal v6.3.2
Snippets enabled: 5
Restricted mode: off
Plugins installed: 81
Plugins enabled: 52
1: Templater v1.16.0
2: Calendar v1.5.10
3: Natural Language Dates v0.6.1
4: Note Refactor v1.7.1
5: QuickAdd v0.17.1
6: Advanced URI v1.33.3
7: Metadata Extractor v1.1.0
8: Advanced Tables v0.18.1
9: Dataview v0.5.55
10: Periodic Notes v0.0.17
11: Readwise Official v2.0.1
12: Matter v1.1.4
13: Local REST API v1.5.2
14: Zotero Integration v2.3.8
15: Regex Find/Replace v1.2.0
16: Obsidian42 - BRAT v0.6.36
17: Tasks v2.0.1
18: Super Simple Time Tracker v0.1.6
19: Projects v1.13.0
20: Daily notes opener v2.0.2
21: Auto Note Mover v1.2.0
22: Spotlight v0.2.0
23: Snippetor v0.2.7
24: DB Folder v3.3.2
25: Minimal Theme Settings v6.3.1
26: Media Extended v2.11.1
27: Hidden Folder v1.0.7
28: Commander v0.4.9
29: Canvas Conversation v1.1.1
30: Obsidian Plugin Manager v0.1.4
31: Banners v1.3.3
32: Homepage v2.8.2
33: Style Settings v1.0.3
34: Tag Wrangler v0.5.7
35: Text Generator v0.2.21
36: Settings Search v1.3.7
37: Paste URL into selection v1.7.0
38: Tracker v1.10.9
39: Reading Time v1.1.1
40: Plugin Update Tracker v1.4.6
41: TagFolder v0.15.22
42: Contextual Typography v2.2.4
43: External Favicon v1.1.0
44: Force note view mode v1.1.1
45: Excalidraw v1.8.21
46: Buttons v0.4.19
47: Obsidian Better Internal Link Inserter v1.0.0
48: ChatGPT MD v1.4.3
49: Icon Shortcodes v0.9.7
50: Supercharged Links v0.9.5
51: Obsidian42 - Text Transporter v1.0.3
52: List Modified v2.1.3

RECOMMENDATIONS:
Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.


Next time please follow the Debug Help directions at the top of the template that you filled out. Does this happen in the Sandbox vault?

Slightly older pic, but the Apple extended US English keyboard looks like this:

What’s your keyboard layout and what is your OS language set to? Until it’s looked into, you could try adding another modifier, e.g. ⌘ + shift + <

The instructions state:

Before opening a new bug report, please search the forum for duplicates and read the Debug Guide.

I did that but didn’t find any duplicates.

We only consider bug that are reproducible in the sandbox vault or no third-party plugins/no css snippets/default theme. For Linux, we only accept bug reports that are reproducible with the Appimage package under Gnome or KDE.

The behaviour I described is reproducible in the sandbox vault.

Once you’ve done the above, delete everything above this line.

I did that. Plus the line itself.

What else was I supposed to do?

Yes.

I included a screencast showing the keyboard layout. It is the Swedish keyboard layout.

English

Same issue with that one. ⌘ + shift + < registers as ⌘ + shift + ,

The information on that page is helpful:

Note for non-US users: Even if the hotkey you type doesn’t match on screen with what you would expect to see (given your keyboard layout), it will work fine following the actual buttons you pressed (as long as you don’t change layout).

The hotkey that appears on screen is the one that you would have to perform if you were using a US keyboard.

But the problem is that although ⌘ + < does seem to work despite it being displayed as ⌘ + ,, the conflict with ⌘ + , is real, i.e. ⌘ + , will now trigger the same command that ⌘ + < was registered for. So this is not merely a matter of the hotkey being displayed wrongly, it also seems to be registered twice (which adds the confusion that the wrong display of the hotkey causes).

So, from what I can see, there are two issues here.

  1. Users on non-US keyboards will sometimes see the wrong hotkey displayed. That one is known (I assume the explanation on the help page means something like: “we know this is not ideal, but haven’t managed to fix it yet”).
  2. Users of non-US keyboards will register two hotkeys whenever the key in question differs between the US-keyboard layout and the keyboard layout used.

We have never seen this happen. What is your keyboard layout?

Are you sure that two physical buttons are mapped to the same command or is this just a matter of things being displayed wrong?

Thank you for following the BR template. You didn’t mention in your original post that you tried in the Sandbox, restricted mode, etc. That’s why I asked.

@WhiteNoise They mentioned above that it’s a Swedish keyboard and the OS is in English.

If you’re all using a US keyboard, that is not surprising. But you should be able to reproduce this in the sandbox vault:

The keyboard layout is Swedish (SE).

We can leave the physical keyboard out of the picture. As you can see in the screencast above, the issue exists also when using a virtual keyboard.

No, there are two issues. One is that things are displayed wrong, the other is that the hotkey that is displayed is also active as a hotkey (in addition to the hotkey that is not displayed anywhere).

So, when non-US users register ⌘ + < (or any other key that somehow doesn’t match the US keyboard layout) as a hotkey for command A, they get the following:

  1. Instead of ⌘ + < being shown next to the command A, ⌘ + , is shown.
  2. If they press ⌘ + ,, command A is executed (which is expected behaviour based on what is displayed in the hotkey list, but which is not expected behaviour based on the fact that the user registered ⌘ + < for that command.
  3. If they press ⌘ + <, command A is executed, which is expected behaviour based on the fact that this is what the user registered, but once the user forgets which key they registered for command A (I won’t blame them!) that behaviour is totally unexpected.
  4. If they now - after forgetting that they already registered the ⌘ + < - have this great idea that they could use this as a hotkey for another command B and do so, pressing ⌘ + < will not trigger command B but still command A. Also ⌘ + ,, which is now also displayed next to command B still triggers command A. (not sure why, but it appears that only the default hotkeys are overwritten by new, conflicting hotkeys, while custom hotkeys are retained when a new conflicting hotkey is added.)
  5. If the user now removes the hotkey displayed next to command A (⌘ + ,), the effect is that ⌘ + < will now trigger command B. (Seriously, I am not kidding you! :rofl:).

ok. the fact that the what you press does not correspond to what you see on the screen is a known issue of non-us layouts.
The fact that two different keys are detected as the same is new.

This is not reproducible on windows because on windows the swedish keyboard does not have the < in the lower left corner.

I use a Swedish windows keyboard with my mac and it does actually have a < key in the lower left corner.

Sorry, you are correct about that.