Yeah, I'm one of those people. You know. The ones who use an alternative keyboard layout. Also I'm running Arch Linux too, if you need to know the OS.

So, Pico-8 works great with Dvorak, but there are a few instances when it does weird things. The one that comes to mind is in the Sound Editor. For the top letter row (qwertyui on Qwerty) (',.pyfgc on Dvorak) (;,.pyfgc on Programmer Dvorak), you are still able to correctly enter the correct notes as you would expect (cdefgabc).

BUT as you see with both Dvoraks, the comma key = note D, the period key = note E. Unfortunately the comma key is also mapped to speed up and the period is mapped to slow down. This has been bugging me for a while.

I would suggest a fix by mapping all the shortcuts (at least in the sound editor, maybe other ones) to the key code/location on the keyboard instead of whatever the user has the key mapped to (keyboard layout).

Let me know if you have other suggestions for a fix. And thanks!

The location on the keyboard isn't something that a keyboard easily conveys via hardware; it only sends keycodes that the OS transforms into useful input.

As a fellow Dvorak layout user (non programmer version; on a TypeMatrix 2030), I'm with you on changing them, but this is a ripe case for configuration, which can default to the current keys and weirdos like us can tweak it for ourselves. :)

I checked my ~/.lexaloffle/ dir, and there's already a config.txt PICO-8 uses. No signs of key config, though. Maybe @zep would be interested?

Perhaps extend keyconfig to also be able to map editor keys?

It's been over a year; any news on this front?

I haven't really tried anything. I've just been living with it. When I edit music, I usually switch to qwerty so that it isn't as annoying. It would be nice if this was changed/fixed. And it is a bit weird that some keys are switched based on your keyboard layout and some are not. It's like there are two different ways SDL is checking what keys are pressed.

If you're comfortable doing a bit of hex editing, you could fix it yourself. Find this sequence of bytes:

1D 00 00 00  16 00 00 00  1B 00 00 00  07 00 00 00
06 00 00 00  19 00 00 00  0A 00 00 00  05 00 00 00
0B 00 00 00  11 00 00 00  0D 00 00 00  10 00 00 00
14 00 00 00  1F 00 00 00  1A 00 00 00  20 00 00 00
08 00 00 00  15 00 00 00  22 00 00 00  17 00 00 00
23 00 00 00  1C 00 00 00  24 00 00 00  18 00 00 00
0C 00 00 00

On 0.1.12c Linux x64 (md5 e85b44201c9b84c9373d3dfe2ea2b687), it's at offset 251840.

That's a sequence of SDL_SCANCODE values representing the keys corresponding to each note. They're from lowest to highest, so 1D is Z, 16 is S, and so on. Just edit those, and there you go. I haven't tested enough to say if it causes any problems, but I wouldn't expect it to.

Scancode definitions: https://hg.libsdl.org/SDL/file/8a4b1beb4f6e/include/SDL_scancode.h

That isn't exactly what I wanted, but it works! And it's pretty clever. I remapped the top two rows of notes, so that the "Q W , ." keys don't conflict with each other. Specifically, I moved the top "C D E F G A B C" to "4 5 6 7 8 9 0 -" and "C# D# F# G# A#" to "r t u i o". Here is my new sequence:

1D 00 00 00  16 00 00 00  1B 00 00 00  07 00 00 00
06 00 00 00  19 00 00 00  0A 00 00 00  05 00 00 00
0B 00 00 00  11 00 00 00  0D 00 00 00  10 00 00 00
21 00 00 00  15 00 00 00  22 00 00 00  17 00 00 00
23 00 00 00  24 00 00 00  18 00 00 00  25 00 00 00
0c 00 00 00  26 00 00 00  12 00 00 00  27 00 00 00
2d 00 00 00

But it would be nice for this to be fixed for good in the future.