AutoHotkey Community

Many people have been thinking about this for years.

There's no reason to restrict the scope resolution operator :: to only handle hotkeys.

Let users define their own functions to handle

• multi touch (pinch to zoom)
• mouse gestures
• voice
• whatever the future brings (camera, Hololens)

EDIT: Would also remove the need for OnClipboardChange, OnMessage, OnExit as special event handlers and streamline syntax.

It would force the user to define their own handlers, which could then be run on a loop.

What do you think?

"restrict" lol. also, ahk doesnt have a scope resolution operator. also, :: is not an operator

Generalize the double colon to be a global event handler
Let users define their own functions to handle

what does that even mean?

Would also remove the need for OnClipboardChange, OnMessage, OnExit as special event handlers and streamline syntax.

how so? :: is evaluated at compile time, which is why functions like Hotkey(), Hotstring() and these have to exist. how does it streamline the syntax?

tldr: i have no idea what ure suggesting

Only read the title. This is sonething Ive been thinking about for a long time. AutoHotkey is an event-driven language with regards to hotstrings and hotkeys.
The syntax to define functions and objects and similar is highly extensive.
Users can make their own functions and objects and extend AutoHotkeys basic features in that regard.
However the Hotkey syntax - arguably the most iconic - cannot be extended.
Users aren't able to define their own event sinks and own event providers.

Sadly I struggle with the same questions as swagfag.
When is what evaluated. If we just evaluate everything at startup the system will be highly undynamic and we have the same problem as hotkeys - which resolved those with a Hotkey function.
If we make the system highly dynamic we completely change the way the system works and completely throw away the most basic syntax most newbies use.
A mixed system with both options provided might be seen as overcomplicated.

To make your proposal useful, it should include examples of existing libraries that could make use of this syntax, along with specific examples of how the syntax should look. It's hard to justify (vaguely undefined) new syntax features that will only be used by non-existent libraries.

But in actual fact, there are at least two scripts handling mouse gestures, probably more. Mine gets by just fine with normal labels (: syntax "extensions"). I'm fairly certain voice recognition has been done as well. If there's anything stopping people from handling multi touch, Hololens or anything else, it's probably lack of expertise or motivation, definitely not lack of integration with the :: syntax.

OnClipboardChange, OnMessage and OnExit are just functions, using ordinary function syntax and callbacks/function objects. Their usage is similar to OnEvent (Gui), and can be emulated by script fairly easily. Integrating these types of events into the :: syntax would not remove the need for these functions. That should be obvious, since we already have OnExit: and OnClipboardChange: in v1, and we still need the Hotkey function and recently added Hotstring function despite having :: syntax for those.

Two user defined function or class libraries are much more likely to be usable within the same script than two language extensions which try to utilize the same syntax.

The :: syntax is based on label syntax, and has the drawback of being unable to clearly define the bounds of the associated procedure or establish a scope for local variables. (Using braces is currently no better than using comments, since execution passes through them.)

The advantage of the :: syntax is that it is easy to get immediate, useful results. Even with integration, at the very least, the user would need to #include the appropriate library to enable whatever type of event they're trying to catch. The user then also needs to know (or look up) how to write the :: line for whatever they're trying to handle, vs. how to do the same with a function or method call (which should also be an option anyway).

In another language, everything might be done with just call statements and blocks. For example, Each type of event just needs a function to register for that event. Anyone can write a function.

nnnik wrote: ↑

10 May 2020, 03:14

If we make the system highly dynamic we completely change the way the system works and completely throw away the most basic syntax most newbies use.

Ironically, AutoHOTKEY's hotkey syntax felt the most outdated. Just provide newcomers with good deal of simple "know-how" Hotstring() examples covering most of usage cases so ppl could copy-paste. Having simplified functions-only design would reduce learning curve eventually. And this double colon operator could be used for something else. I believe AHK outgrown its name: the language is not focused on writing hotkeys but has become a universal tool for different tasks.