Hotstring E(xecute) vs E(nd chars), Hotkey directives Topic is solved

Discuss the future of the AutoHotkey language
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Hotstring E(xecute) vs E(nd chars), Hotkey directives

26 Jan 2018, 19:20

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:

Code: [Select all] [Download] GeSHi © Codebox Plus

#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
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.
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

27 Jan 2018, 00:04

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.

Code: [Select all] [Download] GeSHi © Codebox Plus

#Hotkey NoSuspend
#Hotkey Suspend0
#Hotkey CanSuspend0
#Hotkey S0
#k::

Suspend Permit wasn't the best either; it's not permitting Suspend, but permitting the hotkey to run when the script is suspended.
User avatar
Exaskryz
Posts: 2856
Joined: 17 Oct 2015, 20:28

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

27 Jan 2018, 01:26

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.
User avatar
Drugwash
Posts: 560
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

27 Jan 2018, 03:59

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! :)
User avatar
jeeswg
Posts: 4280
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

27 Jan 2018, 05:31

Good re. execute hotstrings:
- X

Possibly the best I've seen re. Suspend:
- CanSuspend (on by default)

Other ideas (based on text in the documentation):
- SuspendPermit (on by default) [opposite meaning to 'Suspend Permit']
- SuspendExempt (off by default)
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

27 Jan 2018, 21:04

Thanks for the suggestions.
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.

jeeswg wrote:opposite meaning to 'Suspend Permit'
That is a good reason not to use it.
Noesis
Posts: 276
Joined: 26 Apr 2014, 07:57

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

28 Jan 2018, 01:09

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 perhaps
AllowSuspended,
SuspendIgnore.

Anyway, just my thoughts.
Helgef
Posts: 2900
Joined: 17 Jul 2016, 01:02
Contact:

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

29 Jan 2018, 14:45

lexikos wrote:Thinking about future expansion...

It isn't a good syntax to build on, imho.
Perhaps "X" for "eXecute" is a suitable alternative.

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

Code: [Select all] [Download] GeSHi © Codebox Plus

::btw::send("by the way")

and save the X for regeX :). Then there wouldn't be much need for the sendmode (T SI SP SE) and keydelay (Kn) options.
Hotstring("Defaults", "Options")

Another idea, HotstringOptions("Options") and HotkeyOptions("Options") .
#Hotkey NoSuspend

The question is, would the above affect hotstrings? I suggest #NoSuspend / #CanSuspend for both, since suspend(true) suspends both hotstrings and hotkeys.

Code: [Select all] [Download] GeSHi © Codebox Plus

#NoSupend
f1::exitapp
::abc::123
#CanSuspend
f2::msgbox

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 :thumbup:

Cheers.



off topic
User avatar
jeeswg
Posts: 4280
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

29 Jan 2018, 15:15

- @Helgef: I like R for RegEx. X is great for eXecute.
re. off topic
Last edited by jeeswg on 30 Jan 2018, 19:54, edited 1 time in total.
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

30 Jan 2018, 03:16

Helgef wrote:It isn't a good syntax to build on, imho.
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
Helgef
Posts: 2900
Joined: 17 Jul 2016, 01:02
Contact:

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

30 Jan 2018, 09:35

jeeswg wrote:- @Helgef: I like R for RegEx. X is great for eXecute.
Fine, then maybe A for rAw? ;)
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
User avatar
jeeswg
Posts: 4280
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

30 Jan 2018, 10:01

- used: B C K O P R SE SI SP T Z
- remain: ADFGHJLMNQUVWXY EISP
- E (end), X (execute), G for RegEx perhaps.
- E (end), X (execute), R for RegEx, A/W for raw. (Although I tend to avoid changing a definition.)
- Like with the Format function, letters are at a premium.
User avatar
nnnik
Posts: 2791
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

30 Jan 2018, 10:29

End for end, execute for execute, regex for regex and raw for raw.
Recommends AHK Studio
just me
Posts: 5335
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

30 Jan 2018, 11:43

Urgh! I'd have to type too many letters then. God preserve us! :lol:
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives

31 Jan 2018, 04:15

Raw (R) is obsolete; I can't imagine any situation where I would recommend it over the Text (T) mode.

(I intend to remove SendRaw and ControlSendRaw for this reason, though I'm not sure whether I'll replace them with 'Text functions. To be clear, I don't intend to remove {Raw}.)
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Hotstring E(xecute) vs E(nd chars), Hotkey directives  Topic is solved

10 Feb 2018, 21:10

I decided to go with "X" and leave Hotstring(Options) as-is.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 3 guests