Not able to use '@' for tags etc. due to conflict with Alt Gr key

Steps to reproduce

Press Alt Gr+2 on a Danish keyboard or any keyboard that has @ mapped to that key. Like here: http://fontmeme.com/images/danish-keyboard-550x183.png

Expected result

To insert the character ‘@’ (like it is confirmed to work everywhere else in Windows on the PC).
So that I can use @-tags etc. etc…

Actual result

Font changes to bold and a bigger typeface (visible if I start typing other characters).
This only happens in the content field of a DL document. Not anywhere else. I can name a document or folder with @ in the name as well (ie. same browser window) without problems.

Environment

Chrome, latest version on Windows 10.


Additional information

Anything else you think would help our investigation, like a screenshot or a log file? You can drag and drop screenshots to this box. For large amount of text, try putting them into something like Pastebin.


Additional comments

Hi @Lasse_Pedersen,

Sorry to hear about this. We try to support some keyboard layouts (see here: http://help.dynalist.io/locale-shortcuts/), but Danish is not one of them at the moment.

If you only use @ but not #, you can switch to the Czech keyboard layout as a workaround. Really sorry about that!

Wow, that’s really a set-back! :worried:
Especially because it is one of the two tagging prefixes.

But I don’t understand the technical problem. You already have a neat feature allowing users to remap keys. Isn’t this simply a matter of including those features mapped to that key as well?

My bid is that you will have to address it sooner or later. Nobody will expect a global web application to have challenges with localization. Especially not in the web browser itself…

The thing is we’re not able to know what keyboard layout you’re on. English layouts use Shift+2 to type “@”, which requires AltGr+2 (AltGr is equivalent to Ctrl+Alt), and that triggers the set heading shortcut.

If you took a look at this link (http://help.dynalist.io/locale-shortcuts/), you’ll find that heading shortcuts are not the only problem. Things like [, ], and other shortcuts that contain Ctrl+Alt also have trouble with Alt Gr keys.

Two solutions that could solve this for good:

  1. Never ever use the Ctrl+Alt combination in shortcuts. This, however, makes setting default shortcuts very hard. Most Ctrl shortcuts are taken, and all we have left is Ctrl+Shift shortcuts.

  2. Make customizing shortcuts a free feature. This is not as good as solution though, as not everyone would have the time or energy to set their own shortcuts.

It would be ideal if we can know whether you’re on a keyboard layout with Alt Gr keys, but as far as I know, it’s not possible. It’s equivalent to pressing Ctrl and Alt at the same time. We know making things work for Alt Gr key is important, but it’s not reasonable either to assume everyone is on Alt Gr, as the majority of our users aren’t.

It’s a difficult problem to solve, and our solution right now is to have a keyboard layout option that you can tweak yourself :frowning:

@Lasse_Pedersen a workaround could be to use AutoHotkey to map another key(combination) to output the @ character

All right - so Ctr+Alt equals Alt Gr - I didn’t know that. So I couldn’t see a solution in the key remapping feature either.
I can see that the custom remapping can work, and I believe that is the best solution.

I use both, so I didn’t check in to this option at first. (Also, I sort of stayed away because changing key maps to other locales usually always messes up something else. If it is really locale mapping that is in question).

I did look into it now. # is on Shift on my keyboard, not on Alt Gr.
So the Czech option works for me so far (I can use both # with Shift-3 and @ with Alt-Gr-2).

So right now I seem to not be affected. Which I am happy about. :birthday:

My suggestion for a long term solution, if custom remapping is to be kept as a paid option (which is fair enough), is to still allow the few keys that are Alt-Gr-affected to be “open” in the free version.
If DL becomes a key tool (for me, if Android gets fully flying and there is some interface with email/IFTTT/Zapier) then I will be fine paying. (Looks like it will).

But if I had this problem, e.g. the “@”, as a free user I would NOT expect that I would have to pay already to have the system not override key functions of my keyboard. Especially not such a central character for the internet, tagging, e-mail addresses, GTD notation etc…
Just my 2 cents as general user feedback.