Execute vs End Chars
I chose the new option "E for execute" over "F for function" (which has been suggested previously) because 1) hotstring() accepts a label (or function) name and 2) a same-line action is not necessarily a function call. However, I've been considering whether it's worth allowing hotstrings to have different sets of end chars, in which case there should be some way to:
- Update an existing hotstring to use the current set of end chars as set by Hotstring("EndChars", ...).
- Specify that a hotstring should "lock in" the last set of end chars set by #Hotstring EndChars.
(Alternatively, it could be the default in v2 and unavailable in v1.)
It's probably more intuitive to always "lock in" the current set of end chars, but this approach would retain compatibility:
Code: Select all
#Hotstring EndChars .
; Hotstrings using above EndChars:
:E:abbrev::abbreviation
:E:etc::et cetera
; Hotstrings using global EndChars (last set in script, for backward-compatibility):
::btw::by the way
::ftw::for the win
#Hotstring EndChars -()[]{}':;"/\,.?!`n `t
Why End Chars?
There are workarounds for the inability to have different end char sets in the same script, such as including the end char and defining the hotstring multiple times, or using a regex hotstrings script. I also tentatively intend to add built-in support for regex, which would provide another way to specify a set of characters for the end of the hotstring. However, end chars may be important for performance: if the last character typed is not an end char (and the hotstring requires one), the hotstring recognizer does not need to perform a full string comparison or regex match. It's also less convenient and less efficient to define a duplicate hotstring for each end char, or to include the end chars in multiple regex hotstrings.
Options
Hotkeys have a few options which, like hotstrings, can be specified as option letters when creating the hotkey: B B0 Pn Tn In. However, the default values for these are set by directives, and cannot be changed (such as before creating a group of hotkeys) while the script is running. By contrast, #Hotstring Options and Hotstring("Options") sets the default options. That won't really work for Hotkey() because the B option is ambiguous (with the B key) and Hotkey's second and third parameters are optional. So I'm considering instead (for v2) Hotkey("Defaults", "Options") (or "Default") and Hotstring("Defaults", "Options"). On the other hand, then Hotstring() and #Hotstring are less consistent, unless the directive also requires the "Defaults" keyword (making it more verbose just for consistency).
For hotkeys, I consider Hotkey("Defaults", "Options") and #Hotkey Options to replace #MaxThreadsPerHotkey, #MaxThreadsBuffer and #InputLevel. (There's currently no directive to set a default Pn option.) If T2 I1 etc. are too obscure, the option strings could support longer names such as Threads2 InputLevel1 ThreadsBuffer Priority1 in both Hotkey() and #Hotkey.