I brought up an idea to use both palm keys together as a way to lock the function layer, whereas used just one at a time, they would do ShiftToLayer, but that’s not the same as what you’re after. It could definitely be done, but I don’t know if it can be done with any of the existing plugins.
One way to do this would be to put the third layer after FUNCTION, but before NUMPAD, and turn both palm keys into Key_KeymapNext_Momentary. This way when you press one of the Fn keys, you get to the FUNCTION layer. If you keep holding it, and press the other, as that key now goes to the next layer instead of a specific one, you’ll end up on the layer after FUNCTION.
You might have read about it among GitHub issues, because originally the palm keys worked exactly this way, and people ended up on the NUMPAD layer.
This is a great tool, but it comes with a big caveat. You MUST define at least two layers above the last lockable layer (usually NUMPAD) - otherwise once you lock into that layer you can overflow the layer array on read by pressing the function key(s) - which then returns scancodes derived from uninitialised memory…
I’m not sure that’s how it works. A blocked key is one that is defined to do nothing. A transparent key is one that is defined to fall through. Neither can be defined in a layer that doesn’t even exist…
Let’s say you defined both Fn keys as layer+1 except on the top layer. When you activate the top layer by any means, if you define Fn on those layers to be nothing, wouldn’t that prevent you from going to an undefined layer? I could be off on my understanding of layer function…just thinking out loud.
This works, as long as the Fn keys are layer-lock keys. If you use Keymap_MomentaryNext (the only kind of “next” layer key we have at the moment), it needs to be present on the target layer too, otherwise when releasing it, the firmware would not know it was a layer key. (Or… hm… I’ll have to verify this… it may not be the case anymore!)
In any case, using MomentaryNext needs quite a bit of care. A perhaps safer approach would be to use the MagicCombo plugin.
You would know better… I thought for some reason that when you pressed/held a key on a layer, even if the layer changed, that key definition would remain the same until released and pressed again, at which point it would take on the definition of the new layer.
This seems like a good argument for including a variable that stores the total number of layers in the sketch file (determined with a sizeof()). That way Kemap_MomentaryNext (and potentially other things) could include a check to make sure it doesn’t read past the end of the array.