Thinking about future expansion and consistency with hotkeys, I'm considering some changes to the new hotstring functionality. (This relates to both v1 and v2, but is primarily about choosing the right syntax for v1.1.28.00.)

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.)

"E for end chars" is perhaps more obvious than "execute" and is also consistent with the Input command's "E for end chars" (vs. end keys). However, I'm not sure if "F" is really suitable or if there's a better way to handle the end chars. Perhaps "X" for "eXecute" is a suitable alternative.

It's probably more intuitive to always "lock in" the current set of end chars, but this approach would retain compatibility:

This would automatically allow #Hotstring E to apply the new behaviour to all hotstrings by default. Then if the option becomes default behaviour in v2, it is easy to remove this one directive.

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.

We also need a substitute for Suspend Permit, which no longer works (and will not be fixed). This worked by having the program check the type of the hotkey subroutine's first line to determine whether it is exempt from Suspend. This worked in the past because each command was its own special type of line.

It does not work in the current v2 alpha because now the "line action type" only differentiates between control flow statements, assignments, expressions and a couple of others. It could work by scanning the first line's expression for a function call to Suspend, but it would be more complex, and still wouldn't work for bound functions or similar. It also would not translate to other languages, if any become supported.

In the first place, having the behaviour be affected by functions which haven't been called yet is just strange.

My current idea is to introduce a directive and/or option to make a hotkey exempt (or not) from Suspend. However, I'm not sure about the syntax. As an option word, NoSuspend is fairly clear, but if it is to be followed by an optional boolean value, causes double negatives (NoSuspend0). On the other hand, Suspend[01] looks like it's suspending the hotkey, not specifying whether the hotkey can be suspended. CanSuspend... I don't know.

I favor the X for eXecute, I had thought about that when I read the first couple of sentences.

One idea that struck me was, since we define options in between the first two colons of a hotstring, is it at all possible or worthwhile (if v2 is scrapping colon hotkey/hotstring syntax? I haven't kept up) to set the end key definitions in between the second two colons? That may get messy with any attempts to make a colon an end character, but, escaping it may be readily achievable.

In regards to options, may it be worthwhile to use a prefix key like @ for options? Hotkey("B") is your key B, while Hotkey("@B") is defining the option?

In regards to No/Suspend, what about "Permitted", "Permissive", "Persistent" (hotkey is always active/triggerable), "AlwaysOn"? Though that may become confusing with #If directives that are context-sensitive.

Hostrings could use X for eXecute or D for Do (if it's not taken). The latter would be somehow in an alphabetical flow with E for End chars. Just saying, I'm not at all familiar with hostrings.

For #Hotkey I'd say Suspendable may be clear enough albeit a tiny bit long. I'd go for clearness over cryptic options any day.

As for Hotkey("Defaults", "Options") and Hotstring("Defaults", "Options"), question is which of the two parameters is more susceptible to be blank or less used/necessary. To align Hotstring() and #Hotstring maybe reversing parameter order would do:Hotkey("Options", "Defaults") and Hotstring("Options", "Defaults")

If anything I said above is plain idiotic just disregard my comment. Good luck!

Exaskryz wrote:is it at all possible or worthwhile [...] to set the end key definitions in between the second two colons?

Possible, maybe. Worthwhile, no. It would complicate the parsing and make such hotstrings hard to read/recognize. I expect it would be very rare for each hotstring to have a different set of end chars. If there is even more than one set, I think it would be used for groups of hotstrings.

In regards to options, may it be worthwhile to use a prefix key like @ for options?

What would make it worthwhile? It would remove the ambiguity, but in a way that prioritizes convenience over readability for something which will likely be rarely used (since it hasn't even existed up until now).

Drugwash wrote:As for Hotkey("Defaults", "Options") and Hotstring("Defaults", "Options"), question is which of the two parameters is more susceptible to be blank or less used/necessary.

With this syntax, both parameters would be completely necessary. One for clarity/disambiguation, the other for the actual options. (I would not make "Defaults" optional even when "Options" is not a valid hotkey, because it would inhibit error detection and invite script bugs.) Both parameters would be equally rarely used, because they would always be used in combination, but only rarely used at all. So no, question is not that.

Hotkey("Options", "Defaults")

This would be susceptible to the same problem as before. Hotkey("B", "Defaults") is still ambiguous, because there can be a function or label named "Defaults". It's also less clear to the reader.

Come to think of it, I suppose Hotkey("Defaults", , "Options") or Hotkey( , , "Options") is more consistent with the current syntax.

Although I wanted to remove inconsistency between Hotkey() and Hotstring(), they are different by necessity. I suppose that Hotstring(":default options:") would be more consistent with the function's other mode, but might be problematic if the author unintentionally omits the abbreviation. On the other hand, Hotstring("Options") inhibits detection of unintentionally blank parameters or missing :opt: prefix.

I think, E should be for End, X for eXecute, makes the most sense, IMO.

With regard to the Suspend, I think the main thing is for the logic to associate true with permitting the key to operate in a suspended script. (so off or false by default). I'm not too phased by the term for the suspend exemption, I'd be happy with the already suggested:NoSuspend,SuspendExempt,or perhapsAllowSuspended,SuspendIgnore.

X for eXecute is suitable in the sense that it is just as unobvious as the other short string options. I have no better idea. Alternatively, you could remove auto-replace and demand an explicit call to send, eg

On the other hand, using #Hotkey NoSuspend for hotstrings would be consistent with the built-in variables A_ThisHotkey et al.

lexikos wrote:Thinking about [the] future...

::btw:: I'm glad you are

Cheers.

off topic

Hotstrings wrote:The Input command is more flexible than hotstrings for certain purposes

For v2, I'd like to see the removal of hotstrings, in favour of improving the input function, combining their strengths, and removing their respective weaknesses. In my fantasy, you'd have the input function return an Input object which would collect key events (and text) for certain contexts, have its own set of options, et cetera. The following is only meant to give a (rough) hint,

i := inputCreate([eventSink])i.setContext(funcObj); #if i.caseSense(true); :C:i.matchInsideWord(false); :?:; ...i.endKeys("space","f1"); #Hotstrings endcharsi.strReplace(; Auto-replace hotstrings "btw","by the way","ftw","for the win")i.regExReplace("abc(.*)123","aaa$1zzz"); where $1 does what one would hope.

- [EDIT:] I find your example quite hard to follow, and it looks very complicated. Although perhaps a bigger, more complicated, more realistic example, would actually be easier to follow. Or 2 versions, using the current/proposed syntax for demonstration.

- Since hotkey objects ...log hotkeys, get extended hotkey info, interact with the *right* window (Hotkey command with FunctionObject example) - AutoHotkey Communityhttps://autohotkey.com/boards/viewtopic.php?f=6&t=29560..., the Hotstring function, and new escaping rules for colons in hotstrings. I'm very happy with what we've got.- [EDIT:] So I'm surprised at the desire for more beyond this. Are you so unsatisfied with the current situation?

- In theory, other ideas could be: hotstrings made of text and/or modifiers (but I don't really need this), and, being able to retrieve the text from what I call the hotstring watcher, to know if a hotstring triggering is imminent/to reset it/to modify it (but I'm fine doing this via Input).- [EDIT:] E.g. hotstrings as sort of reverse of Send, allowing special keys as well as letters of the alphabet to be used as triggers.

- One thing that is potentially useful, sometimes the system goes under heavy load and the scripts forget all hotkeys/hotstrings. A way to refresh them all, without restarting the script, might be interesting. When you try to reload such scripts, it can take up to 10 MsgBox prompts before they reload.- Alternatively, an option to increase the delay between showing the MsgBox. And/or a button to force reload. And/or an option to wait x seconds and force reload with no MsgBox. A sort of opposite of #SingleInstance, for how the script should be closed.

It is a good syntax for heavy, repetitive use. As for future expansion, I was referring only to the changes mentioned in my post.

Alternatively, you could remove auto-replace and demand an explicit call to send, eg

Auto-replace hotstrings have at least one unique feature which would be lost by using Send - case-conformance. Auto-replace hotstrings are not affected by limitations such as #MaxThreads or thread priority, as they do not start a new thread or execute any script code. When regex hotstrings are implemented, auto-replace regex hotstrings should support placeholders such as with RegExReplace. I believe auto-replace hotstrings are used much more frequently than hotstrings with a one-line action plus return.

Then there wouldn't be much need for the sendmode (T SI SP SE) and keydelay (Kn) options.

There would be as much or as little need as there is now. Hotstrings could simply use the defaults set in the auto-execute section. Regardless of whether there are letter-options, you can use a multi-line hotstring to change the settings. Removing the options would be less convenient (and less flexible, since you couldn't specify defaults for all auto-replace hotstrings), and would increase verbosity.

Another idea, HotstringOptions("Options") and HotkeyOptions("Options") .

This is for setting default options which the Hotstring() and Hotkey() functions use. It would not affect hotstrings or hotkeys directly, so I don't think separate functions are suitable. On that topic though, I've considered splitting Hotkey "If" from Hotkey, as I did for the sub-commands of several v1 commands. That was primarily because of the added parentheses and quotes, though for Hotkey "If" there's also the fact that it affects hotstrings.

The question is, would the above affect hotstrings? I suggest #NoSuspend / #CanSuspend for both

That's a good point. Currently auto-replace hotstrings cannot be exempt from suspension.

Off-topic

For v2, I'd like to see the removal of hotstrings

Not going to happen. Hotstrings are the primary use of AutoHotkey for some users, and merging them into the Input() function would inevitably reduce their convenience.

I am planning to revise Input() for greater flexibility, but am not intending to make it some kind of all-in-one substitute for hotstrings and hotkeys. It would perhaps allow you to implement your own hotstring recognition (while still allowing other script functions to collect input temporarily).

jeewswg wrote:- @Helgef: I like R for RegEx. X is great for eXecute.

Congratulations on making it through two sentences without going off-topic.

lexikos wrote: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.

What is hotkey("key") (omitting second and third parameter) supposed to mean, couldn't it just be interpreted as setting the default options? Or, change the B option to Buf / Buffer? Hotkey("Defaults", "Options") is annoying, due to the quotes. Additionally, it implies a special case for both the first and the second parameter, whereas the special case Hotkey(,,"Options") only implies a change to what the options are being applied to.

I've considered splitting Hotkey "If" from Hotkey

On that topic, what about hotkey "ifWin"? Will it stay? I noticed #IfWin was removed, that is why I ask.Cheers

Off-topic

case-conformance.

I overlooked that.

Not going to happen

I'm not surprised .

I am planning to revise Input() for greater flexibility

That is nice. If it will be preceeded by a forum discussion, we can talk more about it then