How can I reverse behavior of KC_1 for programmer layout

[moonrumble]

I would like to swap numbers with symbols in the top row.

I have looked at all the examples available. I believe I have to create a custom behavior using FN keys.

does a macro or shortcut exists which reverse the behavior of the key when shift key is pressed.
https://www.kaufmann.no/roland/dvorak/

[ezuk]

So, there is a simple but not elegant solution to this. It's very possible @jackhumbert can come up with something better. Here's my idea:

1. For your layer 0, go with codes like KC_EXLM (!) KC_AT (@) etc. This solves half the problem -- now you have !@#$% etc. in a single keystroke without Shift.

2. Then comes the not-at-all elegant part:: Make the "Shift" key switch to layer 1 when held (momentary toggle). I say "shift" because it won't be defined as a Shift key on your layout, but as MO(1). It will just be in the physical position you expect Shift to be. Then in layer 1, you have "123456" etc as your top row. And for every other key in that layer, you define it as RSHFT(KC_A), RSHFT(KC_B) etc. So you basically fully duplicate your layer 0, only with RSHFT() wrapping all the keys (except for 1234567)

This would be ugly when looking at the code (and it's really not a clever solution by any means) but I believe it will do what you want it to do.

@jackhumbert what would be the not-stupid way to do this? :) Any ideas?

[DidierLoiseau]

I am currently doing something similar for implementing a BÉPO layout in firmware in order to use it with a Canadian Multilingual OS layout.

I had a similar issue in that some characters in the default layer need to be shifted (easy) but not all characters in the shift layer actually need the shift. (I didn't push it yet so unfortunately I can't show you the code right now)

My solution is a bit different: I use a macro to toggle the shifted layer and at the same time toggle the shift key ((un)register_key(KC_LSFT)). This was inspired by #121.

Then for the keys that don't need to be shifted (all numbers + a few others), I use macros that unregister shift on key press, and register it again on key release.

Note that there is an issue with the RSFT(kc) as the shift might affect the next key if you type fast. I still need to create a ticket for that.

[moonrumble]

Thanks for the comments. I wanted a clean solution. I don't prefer to make a second layer just for 1 to 0. I rather get used to SYMB layer.

I have looked at almost all the examples. If I can query a state of a key, I can then determine if SHIFT key is already pressed or not pressed.

I can try using global variable which sets it true any one or both SHIFT keys are pressed. Ideally, if we should have REVERSE(KC_KEY) which just reverse the behavior of KC_1.

I am trying to understand this code but probably c is not my cup of tea.

[moonrumble]

This is bit different then #121. I wanted to reverse behavior of the key. Instead of a A, I wanted to configured A a.

#121 will help switch to a shift layer using modifier key.

[jackhumbert]

The real problem here is that the OS is interpreting the KC_1 and KC_LSFT keys to generate the ! - you'll have to map something on the OS side if you want a more elegant solution. Currently, the method @ezuk described is the best way to do this.

[DidierLoiseau]

@moonrumble Your problem is indeed a bit different, but #121 would provide a solution for it.

Alternatively, after your previous comment I had another idea: you could implement all numbers as macros that check whether shift is currently pressed. So on macro key press:

• if shift is currently pressed,
  1. unregister KC_SHFT
  2. register and unregister the appropriate KC_0-9 to simulate a type
  3. register KC_SHFT again
• otherwise, return a macro that types the symbol

Note that U(SHFT) would not work in a macro as it does not affect the same bitset as (un)register_code.

You won't have repeating keys (that would be a bit more complex to implement) but I guess it's fine for symbols and numbers.

Note that if you implement it as @ezuk suggests, you will probably run into #156.

[moonrumble]

Thanks every one for the comments. I will close this issue.