Is AHK dead? (not developed any more)

[jeeswg]

- @zapax: You're asking tough questions of this community, and SOTE is asking tough questions of you. I've enjoyed the threads/posts, by both of you, immensely.
- There are one or two people who could be more friendly sometimes, but I think both of you have been OK.

- @nnnik: How's the consortium going, what have people offered so far, what feedback are you getting? Thanks.

[SOTE]

- @tank: Rather than fork AHK, my more pragmatic plan was to make available a really good function library (nearly finished), and to push for the following:

shippable AHK v1 = 'shippable AHK v2'
✓ A_Args object [deprecate legacy command-line parameter variables (%0% %1% %2% etc)]
✓ force-local mode
✓ #Include (support all built-in variables)
✓ ObjCount function
✓ backport AHK v2 functions [deprecate legacy commands]
✓ backport AHK v2 GUI objects [deprecate legacy GUI commands]
✓ documentation [deprecate legacy functionality, complete the index]
_ Loop (expression) [deprecate legacy Loop, essential for two-way compatibility e.g. Loop (var)]
_ LoopFiles/LoopParse/LoopRead/LoopReg [deprecate legacy Loop, essential for two-way compatibility e.g. LoopParse var, "`n", "`r"]
_ #If WinActive() (optimised) [deprecate legacy #IfWinXXX, essential for two-way compatibility]
_ contains/in/is operators [deprecate legacy contains/in/is e.g. if (var is type)]
_ #Include (additional variables) [A_AhkDir/A_AhkName/A_AhkNameNoExt, A_ScriptNameNoExt, A_AhkVersionMain/A_OSVersionMain or other names e.g. 1.1/6.1, e.g. #Include *i %A_AhkDir%\MyScript %A_AhkVersionMain%.ahk]

- Note: I've almost finished backporting the AHK v2 GUI objects, e.g. it worked on the 9 example scripts. Remaining concerns: menu examples, events (very fiddly), .Value/.Text (fiddly).
- All I've ever really wanted was to fix AutoHotkey's syntax problems, to reduce confusion for newbies and to attract devs, and get a StrRept function built-in.

I think your backporting idea is a good one. By narrowing the difference between AHK v1 and AHK v2, it will make it much easier to switch and even encourage switching. And those with big AHK v1 scripts with a lot of code or a large collection of v1 scripts can get continued legacy support to ease the transition. It also seems that backporting will also make your AHK v1 to AHK v2 converter very viable, possibly getting automatic code conversion rates to a significantly high percentage.

[Asmodeus]

I have suggested my suggestion with the consortium to a few people and got mostly positive feedback.
The main reason being that a language simply cannot be maintained and developed by a single person - it's too much work.

Developing and maintaining a project of this size is difficult but not impossible, see Bjarne Stroustrup but that is not my point here.
I think a main problem is AHK's loose structure, lack of management / common vision (don't get mad at me ).

The best example of excellence in leadership I can think of is Ton Roosendaal and Blender. After bankruptcy the community bought the source code for 100k. Today Blender is "highly" profitable, although being also GPL, several full-time developers are paid by "the organization" https://www.blender.org/about/ . This year they even won a Hollywood Award. I believe AHK could extremely benefit from a similar structure & management. To me the consortium is a step in the right direction.