Helgef wrote:Rather the contrary in [my opinion], since you cannot have {Key up} as endkey or have !{key} to mean alt + key.
So these two lists of keys should have different syntax because the functions using them have different capabilities? What if we want to add this capability down the track? In that case, would we use
["!key", "other_key"],
["!{key}","{other_key}"], or reintroduce Send syntax? The alleged problem can be solved by reserving
!#^+ and performing more validation on the key names.
Using arrays of key names (such as those described in the key list), would make more sense and be more readable imo.
imo: For key names, it is not more readable, and makes no more or less sense.
{{} and
{}} are a bit hard to look at, but so is
["""",",","'"] (I suppose
""",'" is only slightly better, and actually, they both looked much worse in the post editor, without the monospace font). With a list of single-character keys other than {/} (like the typical hotstring end chars), a string of characters is more readable, compact and convenient. Even with the braces, Send syntax is more compact. Even if it's a bit more unusual (in general programming) than an array of strings, users likely are - or will become - familiar with Send syntax.
On the other hand, for a string of
end characters, it is probably more intuitive to
treat them as such, not handle them by VK. I considered adding a separate EndChars property to retrieve or set the string of end characters, but didn't want to further add to the code size (yet) if there wasn't much need for it. Then again,
EndKeys can have keys interspersed with end characters when the E option is present, and this complicates the code a little. Removing the E option in v2 and replacing it with an EndChars property might reduce code size. (The Input function could be kept but would not support end characters in that case. Actually, it could be simplified by removing the E option and using {Text} instead, like Send.)
Syntax aside, in my experience,
EndKeys is typically a static list. What advantage is there in constructing an array? The actual end keys are marked in two fixed-size arrays which include all key codes, and the list (with the original naming and order) is not kept. You can build an array piecemeal and then pass it to InputHook, but you could just call KeyOpt for each key or group of keys instead.
joedf wrote: In that case, should there be a warning for blank cases?
No, there should not. An empty case is perfectly valid, either as a means of defining an exception to the other cases when they are not mutually exclusive (for
switch without a parameter), or when the content of the case happens to be commented out. One should be able to write valid code without being nagged.