Autohotkey for Mac

[Getfree]

Forget about the language. AHK is a library of functions and objects.

For example:
- the DllCall function
- COM objects
- windows class names
- pointer sizes on different platforms
- ansi vs unicode strings
- the Send function with its different modes and quirks
- the keyboard and mouse hooks
- clipboard behavior and clipboard formats
- the way shortcuts behave which is tied to specific functionality of Windows

The list is endless.
The language is just syntax for using the library. It makes no sense to make an interpreter for the AHK language if that interpreter doesn't support the AHK library.
And this library happens to be full of stuff that Windows specific. There's no way to port all of it.

You won't be able to build an interpreter of the AHK language that's able to run the endless collection of AHK scripts out there. Period. Just give up.
If you think it's possible to do so, you are not understanding the problem.

Whatever AHK interpreter that could be built for another operating system, it won't be compatible with the Windows AHK interpreter because the library will behave differently. End of story.

[SOTE]

Forget about the language. AHK is a library of functions and objects.

For example:
- the DllCall function
- COM objects
- windows class names
- pointer sizes on different platforms
- ansi vs unicode strings
- the Send function with its different modes and quirks
- the keyboard and mouse hooks
- clipboard behavior and clipboard formats
- the way shortcuts behave which is tied to specific functionality of Windows

Whatever AHK interpreter that could be built for another operating system, it won't be compatible with the Windows AHK interpreter because the library will behave differently. End of story.

What it appears that many people are asking for is to use the AutoHotkey language in a different OS. True, there will be OS specific syntax that can't be used in the different OS, but it's likely many cross-platform users won't mind. I don't think what is being asked, is for 100% exact and duplicate syntax and functionality between AutoHotkey versions for different OSes. The request is not to run "all" Windows OS specific AutoHotkey scripts on the MacOS, but to have a similar language, that can do relatively similar things on the different OS. The trick is to look at what is similar between OSes or what can be common, and built around that, not become stuck on only what is different.

Compatibility, in terms of the script, would be relative to the equivalency of syntax between the AutoHotkey versions. There can be cases of when the syntax will be exactly the same, so a script could work on both OSes. Then there will be cases in which that is not possible, but I would think such dual OS users would mostly not mind. Such people can make the adjustment. We shouldn't underestimate the ingenuity of people to come up with solutions.

Also what you think is "impossible", has already been done with other automation tools, like PyAutoGUI (written with Python). Though I think this tool is inferior to AutoHotkey and AutoIt on Windows and I dislike Python, it does show going cross-platform is possible.

[Getfree]

I'm not talking about automation tools in general. I'm talking about AHK only. The AutoHotkey library is not portable. Some functions in it are, but many others are not.

Now, I you only seek partial compatibility between versions of AHK, then that's indeed possible but you'll only create chaos with that.
Now you'll have "AHK variants" which will be compatible on some things and incompatible on others. That will just cause confusion and frustration on people who try to run an AHK script on their Mac version of AHK, only to find that it doesn't work. And then even more frustration when they find out that their Mac version of AHK cannot run most of the AHK scripts out there because they were written for Windows.

Anyways, I won't reply anymore to this topic, the situation is clear to me. The possibility to create a partially compatible AHK interpreter exists and if somebody feels it's a good idea they can go ahead. But I wouldn't bet money on it.

[SOTE]

AutoHotkey already has different variants that are not 100% compatible with each other. AutoHotkey_Basic (original version) scripts are not 100% compatible with AutoHotkey_L (present version). AutoHotkey_H (https://www.autohotkey.com/boards/viewforum.php?f=65) is not 100% syntax compatible with AutoHotkey_L . AutoHotkey v1 is not 100% compatible with AutoHotkey v2. AutoHotkey users have tolerated these differences quite well, with many people happy with using the different variants. I have enjoyed using both AutoHotkey_L and AutoHotkey_H, and like that there are differences between them.

Consequently, I don't think it's a valid or fair argument to say that AutoHotkey Windows has to be 100% compatible with say AutoHotkey MacOS. If various versions of AutoHotkey on Windows are not 100% compatible with each other, I don't think that if there was an AutoHotkey MacOS, that it's users would have a different expectation about such. What people seem to want, is to see the propagation of the AutoHotkey language and it's ease of use on different OSes.

That people love AutoHotkey so much that they would like to see alternate versions of it on different OSes, is something to be celebrated.

[FanaticGuru]

I'm also not saying such a feat (writing a new AutoHotkey interpreter for the MacOS) wouldn't be tremendously difficult and time consuming, just that it is possible. I think the often given excuse that AutoHotkey must be forever only married to the Windows API isn't a valid one.

Sure, you could redesign a pair of shoes into a pair of gloves. But since each's basic form is a shell for an underlying object, it would be better to just make a pair of gloves from scratch.

AutoHotkey, at its heart, is a shell for accessing the Windows API and DDL more easily.

It would be like taking a book on how to fix cars and translating it to a book on how to fix planes. Better off just writing a book on how to fix planes.

I can definitely see how someone that had a book on fixing cars could think, 'Hey, this book on fixing cars is great! Free and very useful. I wish I had a book like this for fixing my plane.' But then practically nobody would then think, 'Someone needs to translate this book from cars to planes. Just remap every reference in the car book to the equivalent part in a plane.'

What would be more logically is for someone to think, 'This book on fixing cars is a good idea. A book for fixing planes would be useful too. I wonder why I cannot find a free book for fixing planes. I guess they are harder to fix and not as many people have planes.'

FG

[MannyKSoSo]

I agree with FanaticGuru and SOTE here. Although you could do it, I feel that the alternative listed early in this post or apple's own stuff make it to where its not really needed to make an alternative autohotkey version built for mac. I can understand why lexikos doesn't want to have code that could be used on mac version, simply because those functions wouldn't exist on the mac version. It would also look weird with the documents if an autohotkey mac version was built as you would try using a function that is window specific but may not realize it till you tried using it.

The alternative I could see happening is something similar to the way java does it exe's and uses the local systems compilers to generate the executable, but I'm sure most user's would think that their isn't enough functionality or find a specific os alternative to their solution (or in the rare case code it on their own with a programming language for that specific os). However one of the major reason's why I see people come over to autohotkey is its easy and has great and easy to use windows os functions. Most of the people that I know that own a mac don't go out and find a programming language that can solve their needs, but find a full program that has what they need in it and use that, or just don't have the need to use external coding to solve their problems.

In the end I don't think autohotkey will ever have cross compatibility with at least mac (since they are major competitors after all), but linux may eventually have a close windows clone that works with autohotkey.

[SOTE]

While certain people are running around saying, "It's impossible, it's impossible!" There are already automation tools doing exactly what they think is impossible.

PyAutoGUI (coded in python) uses the following:

Note- Members of the AutoHotkey community could look at those APIs/Systems (for MacOS and Linux) or those modules for ideas. Btw, don't like PyAutoGUI and not an advocate for Python, but showing possibilities.

On Windows, uses Win32 extensions and the Windows API.

On OS X uses the pyobjc module to access the Cocoa API.

On Linux uses the Xlib module to access X11 or X Window System

The limitation is arguably in the thinking and possibly programming language/tools (C++) that don't lend itself to cross-platform programming as easily. This is why Tigerlily suggested Lua, there was the IronAHK project (written in C#) that could possibly be restarted, and I have suggested Object Pascal.

In the case of Lua, it is a scripting language that already has interpreters that work on the MacOS and Linux. It may be possible to create a transpiler of select AutoHotkey language to Lua code, which will execute functions on different OSes. In the case of C# a new interpreter has been partially written (IronAHK); the AutoHotkey script could run on different OSes with .Net or Mono, be OS aware, and have different functions for different OSes. In the case of Object Pascal, you would be writing a new interpreter or interpreters for specific OSes, with it being a bit easier as the tools are more cross-platform friendly.

When tinku99 created AutoHotkeyX (https://github.com/tinku99/ahkx/tree/master) for WINE (10 years ago), he used GCC (https://gcc.gnu.org/), instead of Microsoft Visual Studio. And it received a platinum rating on the WINE HQ DB (https://appdb.winehq.org/objectManager.php?sClass=version&iId=17738). So even here, the argument against a cross-platform tool falls flat (as it was done), and it looks quite possible to create alternative versions of AutoHotkey that could work better with WINE. And to the WINE project's credit, it is constantly improving and works on many different OSes (to include Android).

[kaiminjsh]

FanaticGuru !!! I saw your post about how to automate ahk script for auto copy and paste function. Could You please help me by writing to me in PM

[dotm]

I wonder why Hammerspoon hasn't been suggested yet. It seems to be the most viable AHK alternative for macOS. Free, open source, well-documented, feature rich, powered by LUA scripts.