Feature for consideration: Ability to trap ESC sequences or other hot keys

[brucemack]

Thanks to Phil for an excellent library!

I'd like to propose what I think is a simple change that will enable many additional use-cases. My goal is to make it possible for the user to press keys like F1, F2, up arrow, down arrow, etc, and allow the resulting input sequence to be examined and translated into a command, which would then be processed as if the user had typed it directly. So, for example, if the user presses the up arrow and their terminal generates an ESC [ #A, the terminal would be able to convert that into an "up" command which would then be processed accordingly. (Not sure if that's the right escape sequence, but hopefully you get the idea.) Note that in this scenario there would be no return key press required - the "hot key" would be sufficient to trigger the command and clear the buffer.

To implement this, I would imagine an optional callback that could be installed in the shell to provide visibility to the user's input as it was being formed, but before the return key (or ; key) was pressed. Each time a key is pressed the callback would be fired and would pass a sneak peek of the text that had been entered so far. The implementation of the callback would hunt for any special input sequences and, if desired, could return a string that would be treated as the command input. The user's actual input would be discarded if a command was returned. Nothing would change in the command registration or processing code.

I use this library for radio/communication devices and it would be nice to be able to hold down the up/down arrows to be able to quickly tune through a range of frequencies, or press F1 to key/unkey a transmitter, etc.

If there is openness to this kind of feature I can sent a PR for comments.

Thanks,
Bruce

[philj404]

This is getting less simple... I can see where it is handy for key buttons to control "Volume UP" and "Volume DOWN", but it's starting to wander away from SIMPLE.

The command line interface really wants to process a line at a time. Peeking at incoming lines and doing something implies erasing the consumed data (but not the rest of the line).

(Now that that is out of the way) ... The shell just attaches to any Stream and not directly to the hardware Serial port. Could we delegate the interpretation of escape sequences to a special Stream object?

#include <SimpleSerialShell.h>

class HotKeyDetector: public Stream {
    // Pre-process escaped key sequences for immediate response (no waiting for <enter> key)
    // This class can call a function directly, or translate it to a command-line equivalent ("volume MUTE\n")
    // (a translated command will echo the new text and command prompt)
   ...
};
HotKeyDetector remoteButtons;

void setup() {
    Serial.init(115200);
    remoteButtons.attach(Serial);  // volume, mute, play/stop...
    shell.attach(remoteButtons);
    ...
}
...

This is a similar to your idea, but delegates the "optional callback" into the Stream it reads.

Would this be sufficient?

[brucemack]

Thanks Phil. Just to be clear: I was not proposing anything sophisticated along the lines of erasing consumed data and leaving the rest of the line. If the callback sees a hot key if interest, it would return the command and all buffers would be flushed. Trying to understand how the hot key relates to previously entered text seems too complicated.

Anyhow, is was worth a try. Sorry if it seemed too complicated. We can close this one.

Have a good weekend,

Bruce

[philj404]

I did some experiments with Arduino and PlatformIO (under Windows). Their Serial Monitors (by default?) seem to be too simple to pass in escape sequences for function keys. I only saw the escape key. Other keys tended to refresh the (local) screen or switch focus, rather than get forwarded to my Arduino Nano. So the sophistication would be lost on most users of this library.

On the other hand, with the appropriate terminal software I think a daisy-chain of Stream objects could do what you want. One object would detect and pull out key escape sequences and do your special thing. Otherwise it would forward any characters that did not look like an escape sequence, and the shell could do the rest.

I think this would be an example of the "Chain of Responsibility" design pattern. The code might not even look that different from what you had in mind. It would be a bit more more clearly separated from the rest of the shell.

You have a good weekend too. Good luck!