Key id symbols wanted

Configuration question
41

Admittedly, it can be solved by refactoring variables and introducing typing…

edit: actually no, that just moves the problem elsewhere

42

This seems like a non-issue to me. Internally, key ids are numbers. When specifying them in a command, the macro engine would translate the symbol to a numeric id. When encountering the register syntax, the engine would naturally use the numeric value.

43

Well, yes, given that key id symbols can be distinguished from numbers…

44

I don’t see what the problem is. Given

setReg 1 2
ifKeyActive #1 tapKey b

Register 1 would store the numeric representation of the 2 key. Then the stored register value would be used by ifKeyActive. What’s the problem with this example?

45

Wasn’t the original issue that there was a request to use actual symbols instead of key ids, i.e. ifKeyActive x tapKey y instead of ifKeyActive 21 tapKey y

But how do you distinguish a key id then from the symbols 1, 2, 3 etc (referring to the key with legend 1!, 2@, 3# etc.

1 Like
46

It’s just a matter of syntax. $1 or id:1 would be viable candidates to represent numeric ids.

1 Like
47

Yes, I agree. Either make key ids it’s own data type with appropriate syntax, or give a symbol it’s own syntax, e.g. ifShortcut 'x tapKey y…

… where ' could mean “replace the next symbol with the key id that it is mapped to”?

48

Please, lets not make the language more perlish than it already is.

Also, when using special operators, please, lets not make them depend on both the data type and the command.

It stands to reason that if a command ifKeyActive accepts variable expansion, it should accept any such expansion, such as %1, or even a raw number etc.

It also stands to reason that if a ifKeyActive accepts keyids as well as variable expansions, you should be able to save the keyid into a register using the same syntax. I.e., setReg 1 c, which obviously brakes on numbers.

Sorry, I don’t understand what these examples mean. Do they correspond to KEYID = 1, or to a KEYID of a key that has 1 printed on it?

49

From the get-go, I propose making the KEYID syntax consistent with KEYABBREVs, meaning that KEYID values like 1 and leftShift would correspond to keys with the relevant texts printed on them according to the QWERTY US layout, just like KEYABBREVs.

We could use a namespace syntax for everything else:

  • For raw key ids, we could use the id namespace, such as id:1
  • We could introduce additional namespaces, such as dvorak:q and so on.

Given the above, key ids would be universally represented by strings that map to integers internally, possibly via a text-to-integer hash stored in the flash, which is plentiful, unlike the scarce RAM, allowing room for numerous namespaces.

50

Well, how do you save a KEYID into a register?

51

A new setRegKey command would be well-suited to resolve the KEYID syntax to the corresponding numeric value and store it in a register.

52

When thinking about alternative keyboard layouts I think it would be good to keep in mind that a solution should also work for custom layouts. Users of UHK are much more likely to create their own layouts (or at least variants of existing layouts like Colemak or others) than average Joe. Not sure if this applies here, but dead keys also need to be supported in general.

1 Like