I don't know of any major new features that I would want or need in a future AutoHotkey release, but I am curious as to what other people have to say on the matter. I.e. are there any major new features you would like for AutoHotkey in future?

I do know that objects were a revolution, one I did not know would happen, and one whose potential significance I was not aware of. For example with AutoHotkey's own arrays/objects, COM (access to Explorer/Internet Explorer/HTML Help/MS Excel/MS Word), Acc (Microsoft Active Accessibility), WIA (Windows Image Acquisition), AutoHotkey's File object, WinHttpRequest objects, and more recently I'm using Scripting.Dictionary objects and HTMLFile objects.

So maybe there's another revolution I haven't envisaged.

Cheers.

[EDIT:] So ... are there any important, major features that you think that AutoHotkey is currently missing? Myself, I don't use many other programming languages, so none spring to mind, hence why I'm asking.

[EDIT:] From my wish list:
THE FUTURE OF AUTOHOTKEY:
I think these areas should be a priority:
manipulate/retrieve text from:
- windows/controls (i.e. more control types) (Acc.ahk, UI Automation ...) [I've found Acc, some control messages, text via OCR/address space to work for me so far, and haven't needed UI Automation yet.]
- webpages (directly or support common go-between software) (IE/Firefox/Chrome/Edge ...) [We have COM for IE, and Selenium looks like it could be the answer for other web browsers.]
- Windows desktop/folder windows (XP/Vista/7/8/10 ...) [As would be expected, issues with new Windows 8/10 are being identified and resolved, I have found that old messages from Windows XP work on Windows 7 if you send them to the SHELLDLL_DefView control instead of the main folder window, and qwerty12 has helped me with some other long-term Explorer Desktop/Common File Dialog/Common Item Dialog problems.]

The only way to find out about the future is to understand the present.
More specifically to understand AutoHotkeys developments in the future you need to find the element that tackles and solves many problems of the present.
You can only do so by working and collaborating with those that develop AutoHotkey and understanding their problems, finding a pattern within those problems and present a more general solution.
You can also look at other languages and their solutions to get some ideas.
I only develop my code and through experience try to generalize. But I can't tell you what the future will bring as it is also your future, will contain your influence and maybe even your solutions.

- @Guest: So what happened with AutoIt, is it still being developed?
- I always thought that if that happened, the users might move on over to AutoHotkey.
- I started learning AutoIt, and have considered writing wrappers/translators to make it easier for AutoIt users to move over. Although I would be perfectly happy for AutoHotkey users to write code in both AutoIt and AutoHotkey, and might make an 'AutoHotkey functions for AutoIt' library.
- Here is some initial code.
Autoit to AutoHotkey - AutoHotkey Communityhttps://autohotkey.com/boards/viewtopic.php?f=5&t=60439
Implement missing functions - AutoHotkey Communityhttps://autohotkey.com/boards/viewtopic ... 65&t=59670

- I'm not too worried about the future of AutoHotkey.
- Firstly, I don't think any major functionality is needed for AutoHotkey, and increased support for handling external GUIs/web browsers/Explorer can/should be done via external scripts.
- Secondly, the things that I think AutoHotkey needs, I can write myself in C++, although there is the question of who's the decision-maker to approve any additions. Also, I've been working on fully backporting the AHK v2 GUI objects/functions (via AHK code, not by changing the AutoHotkey exe), so we can have 'AHK v2 within AHK v1' for the foreseeable future. From my perspective, AHK v2 was almost complete anyway apart from the Thread and MouseClick/ControlClick functions, which are minor.
- Thirdly, we have various users who know C++. We even have AutoHotkey_H!
- But yes, I would love if the main devs come back, they would complete AHK v2 in a unique way that only they could. I'm not at the 'time to get worried' stage yet, I've pencilled that in for Feb 18th, 3 months since the main devs last logged in. Anyhow, they deserve a holiday, and the people agitating for a fast AHK v2 release have never taken a look at, or tried to modify/add to, the challenge that is, the AutoHotkey source code.

AutoIT came out with a stable release on March 16, 2018. So they are still active, including it's community. And they have a list of developers. Because there is a significant time gap between releases, doesn't mean it's not being developed. It can reflect the thinking that the project is very mature, and that they don't have much more to do or don't have any new ideas for the time being. Unless a developer gets into an unplanned or untimely accident, they will often mention if they are no longer developing for a project.

As for AutoHotkey, it's open source, so has a greater chance of surviving versus closed source. Anybody with advanced programming skills could come along and decide to further develop the program. In addition, there are 3 versions of AutoHotkey. AutoHotkey_L, AutoHotkey v2, and AutoHotkey_H. Thus increasing the odds of a branch of AutoHotkey surviving even more.

The AutoHotkey_H developer, HotkeyIt, is still quite active on the boards. And, we just finished the holiday season not too long ago. People do take vacations and breaks.

AutoHotkey is also organized as a foundation and non-profit LLC (AutoHotkey Foundation LLC). Read this- https://www.autohotkey.com/foundation/. The other members of the foundation, Tank and joedf are also active on the boards as well, in addition to Lexikos and Chris. So even if one of their members is on vacation or busy, they are still running or watching the website and likely could select people to help with development or decide what the next course of action is in the event of a major problem. Arguably, AutoHotkey is in a more secure situation than AutoIt, due to all of the above.