We have previously looked at allowing the other keys as well, of course, as it would be logical. However, let's look at them:burkhard wrote: ↑Mon Dec 05, 2022 7:31 pmI do wonder if that implemented design is wholly optimum, though. Wouldn't it be better for long-press function cycling to simply either fully work or fully not work depending solely on the base key? So. I can understand on the digit keys (plus CHS & EE) it doesn't work at all, but the reason it doesn't work is more because they are digit keys rather than because many (but not all) happen to carry menus on the shifts.
CHS: Can arguably be allowed to longpress.
BKSPC: No. Already has a special functions DROP and CLRSTK which will interfere.
Up/Dn: No: Interferes with BST/SST
0-9 . EEX, R/S: No: Interferes with direct buffer entry.
f/g: No. Longpress already cycles between f, g, HOME.
EXIT: No. Already has special longpress functions CLRMOD and MyMenu on it, and we are targeting it for possibly some more.
/ x - +: No. Interferes with the immediate action at the end of number entry.
So of the complete list, CHS can (arguably) be added. I will discuss it internally for possible inclusion.
Longpress ENTER can arguably work despite it being a menu CPX. I will discuss it internally for possible inclusion.
Standardization is not possible due to the immediate actions which are more desired than shortcuts, so unfortunately this is a half measure which cannot be extended to the rest of the keys without compromising the main function of the keys.burkhard wrote: ↑Mon Dec 05, 2022 7:31 pmLong-press functionality should either apply (fully work) or not. "Half-works" (or ⅔ works in this case) adds a tiny wee bit of potential confusion. It's of course a very minor point, though, and one that won't trip anyone up for too long. So, no great complaint, just a very slight inelegancy.