I believe what you are expecting is a reasonable expectation, but apparently the Calculate Token only supports KM variables that can be evaluated as a number:
The %Calculate%% token returns the numeric result of performing a calculation,
where may be any of the following:
Mathematical formula like (2 + 3)*12 Use any Variable which may be evaluated as a number
:!: Just enter the Variable Name (without the %) in the Calculate token
%Calculate%MyVar + 1%
%Calculate%(MyVarWordsPerSec * 60)/MyVarWordsPerPage%
So although you, and I, expect that this should work:
it does not because, in this case, myKMVar has text and cannot be evaluated as a number.
This also does NOT work:
One might expect that since the CHARACTERS() function returns a number, it should work, but it does not.
I'm not sure if this is a bug, or by design.
Maybe @peternlewis can tell us.
In a calculation, a variable can only (currently) contain a series of numbers separated by commas.
As well, tokens cannot contain % characters within them, so you can't nest them generally.
What you need to do is use the Filter Variable action with the Calculate option on the variable to calculate the value of the variable first, then you can use the variable as normal.
In a calculation field, you can use the CALCULATE function.
I have enhanced the calculation engine for the next version so that variables used in calculations can themselves contain calculations that are implicitly evaluated. So with the Variable set to "235,7*11", you can use %Calculate%Variable% to get the result (30).
BTW, the CHARACTERS function returns the number of characters in the text, it does not calculate anything it.
Yes, I am well aware of that, but CHARACTERS()does return a number, so it is actually doing a calculation. I use the equivalent functions all the time in formulas I have in many other languages. Using the length of a string in the same statement as other numeric operations is often very useful.
IMO, any KM function that returns a number should be allowed in any KM token that does a calcuation, especially: %calculate%CHARACTERS(%myKMVar%)%
To make it clear for the user, it seems to me that the %calculate% token in a text area should work identical to any Action that provides a numeric field.
The problem is not that CHARACTERS() is not allowed, the issue is that you cannot have a percent character within the expression of the %Calculate%expression% token. %Calculate%CHARACTERS(text)% works fine and returns 4.
I will ponder whether I can add bracket matching the the %Calculate% token, since unbalanced brackets would never make a valid calculation. I’m not sure about other tokens what might take calculations and how easy it is to generalise this. I not sure I really want the token parser to have to know what constitutes valid parameters when parsing them.
Sorry for dropping out after my original post. JMichaelTX addressed my thoughts exactly.
I’m sure this has been asked before, but given how (ahem) verbose statements like these are getting, what are your thoughts about using UI tokens (discrete, click-and-drag-able, less error/typo prone) to replace the currently 100% text based input.
Something like the search field in Apple Mail.
Obviously that’s a lot of work, and you must have thought about it already, and the costs likely outweigh the benefits. But I’m just wondering your thoughts on it.
Yep. Here's an example. I will type a few characters, and then pause to let autocomplete appear. IMO, the pause/delay is too long.
After my pause the suggestion will appear highlighted in green. I then press TAB to accept, or ESC to cancel.
Personally, I don't like it and don't use it. I have turned it using this Terminal command: defaults write com.stairways.keyboardmaestro.editor AutomaticCompletion -bool NO
I find it gets in my way more than it helps. I would prefer for the auto-complete to activate ONLY when I press a key (F5 is the Mac standard).
I'm not sure how that would work. It sounds nice, but it also sounds like it could get in the way. But I do get your point. The current method is somewhat verbose, and can easily be corrupted by a simple, unintended, character change.
KM has 3 basic entities that can be used in an Action text box:
All of these are typed in a plain text field.
What would be nice is if it were a special rich text field, like the coding pane for Script Editor, and each of the three would appear in different colors, and KM could parse the text without us having to use the % delimiter.
So, in our above use case, all I would need is:
as opposed to what we have now, which is more difficult to read:
But I really doubt that we could see this for KM 8 (which I think is just about done), even if Peter were to accept it for a future version.
It does not need to be turned on, it is on by default.
Autocomplete is somewhat context sensitive and knows which kind of fields they are. Display Text is a token text field and will complete tokens, so if you type %ICU and either wait 3 seconds or press F5 (or perhaps Shift-F5) then Keyboard Maestro will autocomplete the token for you. The AutomaticCompletion preference lets you turn off the “wait 3 seconds part”. I will drop it down to 2 seconds.
F5 (or maybe Shift-F5) is a standard Mac facility.
I’ll leave you two to continue your musics about improvements to the display of the field.