AutoHotkey Community

lexikos wrote:... I went to considerable lengths to minimize the impact that these new features have on code size. The result is that this build is smaller than the previous one.

Wow nice job, there!

With every single new test build posted here, I feel more and more like the version number deserves bumping to v1.2 due to so many major changes to how AutoHotkey works.

fincs wrote:With every single new test build posted here, I feel more and more like the version number deserves bumping to v1.2 due to so many major changes to how AutoHotkey works.

+1, language is evolving fast, i can't keep up. i'm surprised this stuff is even being considered for v1. personally would've preferred all of this to go into v2. just seems more fitting since v2 nudges users into using functions/expressions anyway.

at one point i remember Lexikos saying that he wouldn't be doing much new dev work on v1 other than bug fixes, guess that's changed, which is completely fine and his prerogative

I had more or less "reserved" v1.2 for minor compatibility-breaking. I have also been entertaining the idea of forking the v2 code base to be closer to v1.x syntax, bringing the new features and many of the more minor compatibility-breaking changes to v1.x and making it easier to maintain. (But I probably won't do it.)

I don't see v2 being complete any time soon, but I want to actually use these features. This is also meant in part as a sort of stepping stone to v2. The further v2 diverges from v1, the harder it will be to get users to switch.

You could also say that all of this is for v2, I just happen to be developing it in the v1 branch. For example, %obj%() calls obj.() and therefore triggers __Call with an empty first parameter in v1, but in v2 it calls obj.call(). Hotkey, SetTimer, etc. in this test build use the equivalent of obj.call().

When test is released as main/stable, I concurr with fincs on the versioning To 1.2

Another, more likely idea I have been entertaining is to bump the version number to v1.2 after back-porting a backward-compatible subset of v2 features. I've already done some work on Loop and some of the object methods.

Related topics:

• Port back StrReplace (as function just like StrSplit)
• Backport v2 quoted literal "strings"/'strings' duality.
• v2 Object methods in v1

lexikos wrote: I don't see v2 being complete any time soon, but I want to actually use these features. This is also meant in part as a sort of stepping stone to v2. The further v2 diverges from v1, the harder it will be to get users to switch.

in your mind, whats necessary to deem it "complete"? whats missing currently and are those necessary? why cant you just call it "complete" right now and then bump additions as v2.01 etc?

just curious. i guess i'm more ansy than most to just get v2 out and become the main branch

I would kill for guicontrol and onmessage function binding in v2 right now.

I know the future of CHID and CGui lies with v2, but for now v1 test builds are just so much more convenient to code in.

Merged - v1.1.20.00.