- @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.
- @nnnik: I don't disagree or agree. I do like that you think big though.
- You suggested that we have one carefully curated list of good scripts.
- But who would have the time/skill to curate it?
- Whereas I thought it would be better that each person posted their own personal list as a post.
- Smaller lists are easier to read, personal lists are more interesting to read.
- Similarly, I would rather that say 5 people wrote a proposal for the ideal AHK syntax, and I could be influenced by all of the ideas.
- Again, those lists would be more interesting than whatever a committee could decide. And I'd have more ideas to consider.
- Syntax lists were touched on here:
your personal AutoHotkey style guide - AutoHotkey Community
v2 docs contribution questions - AutoHotkey Community
- (We do need some guidance, however, for the AHK documentation and source code.)
- One concern is that you'd be frustrated trying to persuade people that we need to 'clean' the AHK syntax, e.g. you'd want to replace the A_LoopFileXXX variables with a class. These ideas have some merit, but at the same time many people would disagree with you or say 'if it ain't broke, don't fix it'.
- I feel your aim is to change AHK so much, it would hardly be AHK any more, and it would be better to start with a language closer to your ideal, and fix that.
- Or, you should fork AHK, and/or you should do a full wish list of your ideal AHK, to see if it could gain traction, before proposing a consortium. I do find your ideas for 'cleaning' AutoHotkey quite interesting and worth considering, but I generally find AutoHotkey sufficient for my needs.
- Your language is quite hopeful, but I'd worry you'd just get annoyed when people disagreed with you, or didn't dislike the proposals, but felt them low priority.
[EDIT:] Swapped the order of the 2 responses.