An alternative to the "Repeat Command Phrases" option

[Pfeil]

As the first non-command spoken phrase option to be implemented, I feel "Repeat Command Phrases" has a number of drawbacks compared to a command that would do the same thing; Therefore, I'd like to request an alternative:

The way I see it, a "{PREVIOUSSPOKENCMD}" token, which would provide the second-to-last command phrase spoken(rather than the last command phrase, like "{LASTSPOKENCMD}", which always points to the currently executing command, provided it's triggered by voice) would enable a regular command to provide the same functionality, but also allow(among other benefits):

• a timeout, so that a command that was executed, say, 60 seconds ago, won't accidentally be repeated
• a whitelist, rather than only a blacklist, of which commands should be allowed to repeat in this manner
• triggering a command repeat by anything other than voice
• providing feedback as to which command phrase will be repeated(mainly to the log)
• repeating a number of times(E.G. "repeat that twice") for any given command(without having to build such functionality into individual commands)

[Gary]

An action could be in addition to the, 'repeat' keywords.  I was trying to put the cookies on the bottom shelf on this one for those that asked for it

[Pfeil]

By "Alternative" I did mean "in addition to", I understand why the feature has been implemented this way

[Gary]

Started thinking over your suggestion, and it looks like I've already gone through the scenario you had described (in fact, there are  code artifacts stuffed in VA). 

Where it got icky is when you start by saying a command (when i say):  'increase front shields'.  'increase front shields' gets popped into {LASTSPOKENCMD}. 
When the next command called, 'repeat' is issued (forgetting about the new, 'repeat' keywords for now), '{LASTSPOKENCMD}' is now, 'repeat' and {PREVIOUSSPOKENCMD} is 'increase front shields' (this is independent of any actions). 
In the actions, you grab, '{PREVIOUSSPOKENCMD}' (which is currently, 'increase front shields') and then execute it.  So far so good.
You say, 'repeat' again, and the {PREVIOUSSPOKENCMD} is, 'repeat' from the last spoken command.  This is where it breaks down and gets wrapped up in a way that I'd rather not implement.

So, this got me thinking about making a token that is like what you had suggested, but doesn't just stop at just the previous spoken command.  It will be something like {SPOKENCMD:X}, where {SPOKENCMD:0} would be the same as {LASTSPOKENCMD}, {SPOKENCMD:1} would be {PREVIOUSSPOKENCMD} and, {SPOKENCMD:2} would be like {PRIORTOTHEPREVIOUSSPOKENCMD}, and so on.  Put a max of like 100 or 1000 or whatever on it.  It would work around the, 'repeat' keywords by not including the repeat keywords in the list (but rather use the repeated command's phrase).  It would still fall into the same scenario I outlined above if used in conjunction with a spoken command to activate it, BUT, it would still allow for things like an alternate device to invoke the repeated command.  Just a thought.

You can see why I've dragged my feet on all this, right? 

[Pfeil]

Ah, that I failed to consider.
Though the proposed "exclude this command from the repeat feature" checkbox also affecting the token could solve that(however it remains a possible infinite loop-situation if the user forgets to check it).

I did think about the "history" style token, but figured that was overkill while still under the impression "{PREVIOUSSPOKENCOMMAND}" would work.
One thing I did consider is that the depth may be important for certain styles of profile, in that if it can be modified, the profile may count on one value, while the user has it set to another.
E.G. if an "AI"-style profile checks whether the user has told it to be quiet X amount of times, and changes "moods" depending on that, such a feature may not work well with a short history.