newRPL: Alpha demo 0.9 released [UPDATED 2017-10-25]

[Claudio L.]

(09-01-2017 05:52 PM)The Shadow Wrote:  Had an idea to make user menus even more flexible and (in some common use cases) more compact. Unfortunately, I'm guessing it would be non-trivial to implement. But I'll throw it out there in case I'm wrong.

Basically, recycle the key code format. Since the actual key will vary, you leave it off. So "..L" would mean "long press on the menu key".

"..P" would mean "do this when pressed, but don't include other VAR menu stuff unless explicitly mentioned with keycodes"

So, let's say you have a program called PROG. { PROG } would, as now, produce a key that works like a VAR menu key: Left shift does STO and right shift does RCL.

But frequently, all you want is a menu which runs PROG, without worrying about the VAR baggage. Currently you have to express that as { << PROG >> << >> << >> } and you don't get the neat flexibility in different modes.

With this new version, you'd just say { "..P" { PROG } }. You don't have to add key combinations that don't do anything, and you keep the mode flexibility.

Unfortunately, as I said, I suspect this would be a lot of work, so I don't have any expectations.

Sorry, I'm not following. If you want PROG so that it doesn't act as a variable just use { { "PROG" << PROG >> } }, no need to add empty programs, or even keycodes.
The long press is reserved for the OS to show help or preview the variable, the alpha plane is reserved for the alpha keys, etc. So there are only a few shift planes that are allowed for a menu key, and those are available to be redefined in the menu definition. Other shift planes and modes are not part of the menu system, but can be redefined with a custom key assignment via ASNKEY.
With a command that tells you which item is visible in the menu from a program, you could write code that "moves" with the menu using ASNKEY.