When will AutoHotkey v2 become main version?

Discuss the future of the AutoHotkey language
zapax
Posts: 7
Joined: 04 Mar 2019, 11:17

When will AutoHotkey v2 become main version?

28 Mar 2019, 17:37

I wonder to what extent the work has been completed. I'm not impatient but curious when it will be stable (no more syntax changes or major change in the operation)
and I should get accustomed to changes. In other words what percentage of second ahk version is ready?
User avatar
Tigerlily
Posts: 377
Joined: 04 Oct 2018, 22:31

Re: When will AutoHotkey v2 become main version?

30 Mar 2019, 04:41

zapax wrote:
28 Mar 2019, 17:37
I wonder to what extent the work has been completed. I'm not impatient but curious when it will be stable (no more syntax changes or major change in the operation)
and I should get accustomed to changes. In other words what percentage of second ahk version is ready?
I'd recommend to slowly/gradually start integrating to v2 now - just start experimenting. It already offers greater functionality and flexibility than v1+, among other benefits.

I am too, however, interested to know the answers to your questions.
-TL
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: When will AutoHotkey v2 become main version?

30 Mar 2019, 08:46

Tigerlily wrote:
30 Mar 2019, 04:41
I'd recommend to slowly/gradually start integrating to v2 now - just start experimenting. It already offers greater functionality and flexibility than v1+, among other benefits.

I am too, however, interested to know the answers to your questions.
Tigerlily, I'm somewhat in agreement with you. There is nothing stopping somebody who is truly interested or wants to use AHK v2 from doing so now. To run both, a person can associate .ahk2 files with v2 and .ahk files with v1. The other way, to get people experimenting with AHK v2 syntax, is by updating AHK v1 with it. The "slow merge" concept.

It appears like some people want to force the issue, where only AHK v2 is officially supported and offered, so that all development on AHK v1 stops. Arguably that's a bit shortsighted. Here are reasons for thinking so:

1. AHK v2 does not have the tools ready to support it.

AHK Studio and AutoGUI are in AHK v1. So you will likely need at least these two to support AHK v2 syntax, and release these updated tools to the public.

2. Debatably, a lot of people with big scripts (with lots of code) or lots of scripts, don't want to rewrite them from AHK v1 to AHK v2

For actual programmers this task might be fun for them, but for casual programmers or non-programmers short on time, it's probably not.

3. Debatably, it's better to slow merge AHK v1 and AHK v2

That is, put a lot of AHK v2 code into AHK v1 and deprecate old commands. This is being done now. For example- StrReplace VS StringReplace

ReplacedStr := StrReplace(Haystack, SearchText [, ReplaceText, OutputVarCount, Limit := -1])

StringReplace, OutputVar, InputVar, SearchText [, ReplaceText, ReplaceAll?]

By slow merging, you are encouraging and preparing people to use the new function, while providing legacy support for AHK v1 scripts that are in use.

Also, through such a merge, you can more clearly identify where AHK v2 code has problems or doesn't work as well as the code it intends to replace. You are making sure that AHK v2 will be a full replacement and add benefits over the AHK v1 equivalent.

4. AHK v2 doesn't have a lot of libraries written for it. Most libraries are using AHK v1

5. Debatably, there should be a completed AHK v1 to AHK v2 converter tool, making the transition easier

This should probably be just as important as making AHK v2 the official release. Jeeswg has done a lot of work on this- https://www.autohotkey.com/boards/viewtopic.php?t=36754

The converter tool doesn't have to be perfect, but if you can get up above 95% accuracy, you have made the argument to force a switch very strong.

6. AHK v2 is incomplete

To make it the official version, the developer has to feel it's complete enough to push a switch over. It should be kept in mind that many people are comfortable with AHK v1, so there is no need to force the issue, unless it's really time to.
gregster
Posts: 8921
Joined: 30 Sep 2013, 06:48

Re: When will AutoHotkey v2 become main version?

30 Mar 2019, 08:57

To run both, a person can associate .ahk2 files with v2 and .ahk files with v1.
Careful, just three days ago, JoeWinograd pointed out his problematic experiences with a 4-four-letter ;) file extension. See here: https://www.autohotkey.com/boards/viewtopic.php?f=37&t=63119&p=269866#p269848
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: When will AutoHotkey v2 become main version?

30 Mar 2019, 17:03

but my man, development on v1 has infact ceased, itll no longer get any new features, unless theyre super trivial to backport from v2 and is slated to only receive the occasional bugfix/qol change here and there.
ppl with big scripts can stay on v1. infact id advise against rewrites in v2. syntax is not the only thing thats changed in v2 and tracking down unexpected bugs stemming from the differences in the way how v2 handles things will be annoying af, no doubt. its also something a converter script isnt likely to handle very well.
ppl starting new big scripts can write them in v2 if they know ahead of time what libs theyre gonna need(if any at all or are confident in their capability of writing ones themselves)
u cant merge v1 and v2, theyre fundamentally incompatible. if in doing so, u give way to v2, ull be breaking v1 scripts. if u instead prioritise v1, well, we'll be stuck with the same historical idiosyncratic garbage, we've been stuck with for the past 2 decades, for years to come.
this converter tool u speak of will have to be slightly more sophisticated than a mere regex-find-replace-for-commands. that much I can already do myself with any ol' text editor. and if it isnt, well, u just got a v1 script transpiled to v2 syntax without having leveraged any of v2's features at all. idk if anyone's got the time, expertise or the incentive to develop the more sophisticated version atm
god, i must sound like a v2 sycophant by now, but id be hard pressed to find a single "v1 thing that works better than v2". it's bad, man. like bad-bad
4. is true, nothing to argue about there
5. ive already addressed
6. cant say much
Last edited by swagfag on 30 Mar 2019, 20:01, edited 2 times in total.
User avatar
Tigerlily
Posts: 377
Joined: 04 Oct 2018, 22:31

Re: When will AutoHotkey v2 become main version?

30 Mar 2019, 17:51

SOTE wrote:
30 Mar 2019, 08:46
Tigerlily wrote:
30 Mar 2019, 04:41
I'd recommend to slowly/gradually start integrating to v2 now - just start experimenting. It already offers greater functionality and flexibility than v1+, among other benefits.

I am too, however, interested to know the answers to your questions.
Tigerlily, I'm somewhat in agreement with you. There is nothing stopping somebody who is truly interested or wants to use AHK v2 from doing so now. To run both, a person can associate .ahk2 files with v2 and .ahk files with v1. The other way, to get people experimenting with AHK v2 syntax, is by updating AHK v1 with it. The "slow merge" concept.

It appears like some people want to force the issue, where only AHK v2 is officially supported and offered, so that all development on AHK v1 stops. Arguably that's a bit shortsighted. Here are reasons for thinking so:

1. AHK v2 does not have the tools ready to support it.

AHK Studio and AutoGUI are in AHK v1. So you will likely need at least these two to support AHK v2 syntax, and release these updated tools to the public.

2. Debatably, a lot of people with big scripts (with lots of code) or lots of scripts, don't want to rewrite them from AHK v1 to AHK v2

For actual programmers this task might be fun for them, but for casual programmers or non-programmers short on time, it's probably not.

3. Debatably, it's better to slow merge AHK v1 and AHK v2

That is, put a lot of AHK v2 code into AHK v1 and deprecate old commands. This is being done now. For example- StrReplace VS StringReplace

ReplacedStr := StrReplace(Haystack, SearchText [, ReplaceText, OutputVarCount, Limit := -1])

StringReplace, OutputVar, InputVar, SearchText [, ReplaceText, ReplaceAll?]

By slow merging, you are encouraging and preparing people to use the new function, while providing legacy support for AHK v1 scripts that are in use.

Also, through such a merge, you can more clearly identify where AHK v2 code has problems or doesn't work as well as the code it intends to replace. You are making sure that AHK v2 will be a full replacement and add benefits over the AHK v1 equivalent.

4. AHK v2 doesn't have a lot of libraries written for it. Most libraries are using AHK v1

5. Debatably, there should be a completed AHK v1 to AHK v2 converter tool, making the transition easier

This should probably be just as important as making AHK v2 the official release. Jeeswg has done a lot of work on this- https://www.autohotkey.com/boards/viewtopic.php?t=36754

The converter tool doesn't have to be perfect, but if you can get up above 95% accuracy, you have made the argument to force a switch very strong.

6. AHK v2 is incomplete

To make it the official version, the developer has to feel it's complete enough to push a switch over. It should be kept in mind that many people are comfortable with AHK v1, so there is no need to force the issue, unless it's really time to.
1. This is simply not true. I downloaded AHK Studio last night, along with AHK v2 and AHK_H v2, and they both run on there just fine, as well as on my trusted SciTE editor I've been using for some time. While they might not support Syntax-with-correct-parameter-order, there are AHK v2 docs that people can simply read like we all have since before syntax highlighting/autocomplete was available. I think it's misleading to say that "they are in v1" because that implies that you can't write v2 code in those editors and have them interpret them correctly. In fact, Evil C has created a tool that lets you swap between any versions of AHK (whether that be AHK v1, AHK v2, AHK_H v2, or AHK_whateveryouwant). Check it out, its very handy and easy to use (thanks Evil C!)

Git: https://github.com/ahkscript/AHK-EXE-Swapper/blob/master/AHK-EXE-Swapper.exe
Forum Post: https://www.autohotkey.com/boards/viewtopic.php?t=6310

2. I agree with swagfag, it is probably not worth rewriting a large script in v2 unless you know that in the coming years that it will be a necessity to rewrite because you will need to keep using the code. Especially given the capabilities that you can swap between running v1,v2, _H whatever you want anyways.. its really not difficult or cumbersome.

3. As a relatively new user of AHK and completely new to programming, I disagree with slow merging. While it can be nice at first when you are trying to figure out how to do things for outdated scripts, in the end it creates confusion and too many unnecssary possibilities to do the exact same thing...yes.. sometimes it is nice to be able to do the same thing with two different command syntaxes.. but if one of the syntaxes lends itself to more flexibility/power than the other, then stick with that one and scrap the other head clutter.

4. true, but this is because v2 is just too new for people to start writing libs in it. as soon as v2 is finalized, people will be much more motivated to write libs in it because they know it won't possibly be ruined by some unknowable/unforeseen update to the source code.

5. I agree with swagfag here too, seems awfully complicated and time-intensive.. and until v2 is finalized, may be a lot of wasted effort and time to create such tool. I know jeeswg has a post on this, but he is waiting until v2 is finalized to move forward with most of it. maybe once v2 is finalized and people start feeling like its a necessity, this tool could come to fruition. Would be a cool too though if it did come to life.. but I just don't see people making this before v2 is finalized.

All good discussion points SOTE - thank you.
-TL
User avatar
Tigerlily
Posts: 377
Joined: 04 Oct 2018, 22:31

Re: When will AutoHotkey v2 become main version?

30 Mar 2019, 22:38

Apologies, but I think we are getting off topic from the OP's topic/question and devolving into a v2 pros/cons rant. While the information is all important, good, and relevant (in ways), let's move this discussion back to the OP's query.

RESTATED:

1. When will AHK V2 be stable (no more syntax changes or major change in the operation)???

2. What percentage of second ahk version is ready? (I think this and the latter question are probably questions only lexikos can truly answer, and unsure if he can either at this point?)

3. When should I get accustomed to changes?
-TL
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: When will AutoHotkey v2 become main version?

31 Mar 2019, 08:56

- lexikos addressed the future of AHK v2, here:
AutoHotkey versions - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=57031&p=242508#p242508
- And fairly recently posted these:
Test build - Obj.Count(), OnError(), long paths, experimental switch-case - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=24&t=47682
Objects - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=57591

- My concern has been: what would the AHK v1 features look like in AHK v2.
- I feel that this has been mostly decided, exceptions are: MouseClick/ControlClick/Thread/VarSetCapacity, which I make suggestions for, here:
conversion logic, v1 = -> v1 := -> v2, two-way compatibility - Page 7 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=27069&start=120

- @swagfag: I wrote a converter. The vast bulk of conversion affects whole individual lines: assignments ('var = value'), commands, directives, control flow statements (e.g. Loop). It's relatively easy to identify these lines and ignore other lines.
- Changes to functions/operators, which my converter script doesn't currently handle, I handled via custom RegExMatch/RegExReplace code. Further to that, my DllCall converter could be adapted to a general function converter. However, I converted all of my scripts without needing to write such a thing.

- Re. conversion. Here are the main scripts I've written that address conversion/parsing. I have overhauled the converter, and will release it perhaps within the next 2 months, and have added some AHK v1 <- AHK v2 un-conversion functionality.
AHK v1 to AHK v2 converter - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=36754
DllCall converter/cleaner (e.g. x32 to x64/x32 two-way compatible) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=31365
indent code (automated code indentation) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=37270
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: When will AutoHotkey v2 become main version?

31 Mar 2019, 10:54

Tigerlily wrote:
30 Mar 2019, 17:51

1. This is simply not true. I downloaded AHK Studio last night, along with AHK v2 and AHK_H v2, and they both run on there just fine, as well as on my trusted SciTE editor I've been using for some time. While they might not support Syntax-with-correct-parameter-order, there are AHK v2 docs that people can simply read like we all have since before syntax highlighting/autocomplete was available. I think it's misleading to say that "they are in v1" because that implies that you can't write v2 code in those editors and have them interpret them correctly. In fact, Evil C has created a tool that lets you swap between any versions of AHK (whether that be AHK v1, AHK v2, AHK_H v2, or AHK_whateveryouwant). Check it out, its very handy and easy to use (thanks Evil C!)
I didn't say that an individual couldn't use or adapt AHK Studio or AutoGUI to work with AHK v2. But rather both tools and authors have not made an official release to support AHK v2 syntax. This is a question that has been asked of both authors, and they have said they don't support AHK v2 syntax for now. Again, this doesn't mean that an individual can't adapt their tools to do otherwise.
3. As a relatively new user of AHK and completely new to programming, I disagree with slow merging. While it can be nice at first when you are trying to figure out how to do things for outdated scripts, in the end it creates confusion and too many unnecssary possibilities to do the exact same thing...yes.. sometimes it is nice to be able to do the same thing with two different command syntaxes.. but if one of the syntaxes lends itself to more flexibility/power than the other, then stick with that one and scrap the other head clutter.
Nobody is stopping an individual user from jumping over to AHK v2. The question is more about forcing the entire AutoHotkey community into AHK v2, which is incomplete, and causing a lot of pain and problems. And for what? The satisfaction of using "new"? Slow merging, which is what is already being done, is debatably the better way to gently migrate the user base into using different syntax and provide legacy support for existing scripts and libraries.
4. true, but this is because v2 is just too new for people to start writing libs in it. as soon as v2 is finalized, people will be much more motivated to write libs in it because they know it won't possibly be ruined by some unknowable/unforeseen update to the source code.
Disagree. There is nothing stopping people from using AHK v2, yet most don't. That is a possible indicator of underlying issues with AHK v2 syntax, comparable functionality, not being seen as a big enough benefit, or ease of use. Forcing people to use something, is not the same as they wanting or liking to use something.

"Backporting" AHK v2 features into AHK v1, would speed up the merge. Then you can deprecate more legacy commands, while encouraging migration and providing legacy support. The same for creating an AHK v1 to AHK v2 converter tool or AHK v2 syntax support for AHK Studio and AutoGUI. This would be an holistic approach, which encourages and not forces migration, and would probably shift the balance more in favor of AHK v2 (in terms of those actually wanting to use it and being the majority of users).

Don't get me wrong, I'm not saying that various points you make aren't valid or good, it's just a matter of perspective.
User avatar
Tigerlily
Posts: 377
Joined: 04 Oct 2018, 22:31

Re: When will AutoHotkey v2 become main version?

01 Apr 2019, 21:10

EDIT: I've decided to PM the users I was talking with directly instead of hijacking this thread anymore - sorry! :arrow:

EDIT2: Okay after popular demand - I've been asked to repost the thread publicly again :lol: to promote more discussion around this topic / issue.

Hi SOTE,

I've taken the liberty of getting in touch with the creator of AHK Studio and I'm now building out the new syntax file to match v2 syntax :) I will update you when it's finished - but it will likely be in at least a couiple months due to my limited time. Also, SciTE already has created a beta v2 lexer for syntax support (and quite possibly it has graduated from beta mode - however I didn't dig deeper into it).
SOTE wrote:
31 Mar 2019, 10:54
Nobody is stopping an individual user from jumping over to AHK v2. The question is more about forcing the entire AutoHotkey community into AHK v2, which is incomplete, and causing a lot of pain and problems. And for what? The satisfaction of using "new"? Slow merging, which is what is already being done, is debatably the better way to gently migrate the user base into using different syntax and provide legacy support for existing scripts and libraries.
Which one is it - no one is stopping someone from moving over to v2 OR people are forcing others to move to v2? Who is forcing who to move to v2? If a finalized v2 was released, its not like v1 will just disappear and no one will be able to access it. Naturally, people will start slowly moving over. It's not the satisfaction of using "new".. it's the benefits in functionality, syntax, and code flow that v2 offers and v1 does not. It's not like v2 as-is currently is just nice and shiny and new and that is the only benefit that it brings - it's mainly practical benefits, not superficial ones like it's "freshness" appeal. I guarantee you that once v2 comes out, people will still slowly move over and there will still be a ton of people asking v1-related questions for years to come. It probably won't be until v3 comes out that people start finally giving up their blood, sweat, and tears they have dropped into their awesome v1 scripts/programs/apps/etc.
Disagree. There is nothing stopping people from using AHK v2, yet most don't. That is a possible indicator of underlying issues with AHK v2 syntax, comparable functionality, not being seen as a big enough benefit, or ease of use. Forcing people to use something, is not the same as they wanting or liking to use something.
I for one have been hesitant to switch because of a lack of knowledge/education about how to do it. I initially thought I could only have v1 OR v2 installed, so once I switched over then I'd be stuck rewriting everything in v2. I don't have that time at the moment.. nor will I ever. I will likely be running v1 scripts for years to come, while I develop new things or similar counterparts in v2. I have been speaking with people, and interestingly a lot of them don't even know that v2 exists AT ALL! This is another thing stopping people from switching over. Another thing is that people are skeptical to put time into the v2 alpha release because it is still alpha and things (potentially big things? guess were not sure) could change in the final release. It already is working great for me though. One thing that I'm starting to realize is all the misinformation flowing around the community about v2. Perhaps we need a thread that is mean specifically for helping understand more about v2, implications of installing/using it alongside v1, major changes to be aware of, tools out there that support using v2 (editors, helper utilities, etc.) because contrary to your statement, each day i continue to find more things created for v2 or at least support it in the v1 counterpart.

Instead of talking about why we should stay with v1 support, we should be talking about how we can move support to v2, so that the community feels supported to make the switch. I think the falacy that there is not support for v2 (editors, etc.) needs to be annihilated - it's not true.. and before I started digging, I thought it was true because of other things I've read people saying about this issue. If you think backporting v2 into v1 is a great idea, then you should do it! I encourage that because I think that would be a cool project.. and you would surely learn a lot. Its just not something I see as a sustainable effort IMHO.. meaning I feel that once that project is finished, maybe many more will have switched over to v2 by then and possibly making your efforts not-so-important.. but maybe not.

Obviously we have differing opinions/viewpoints on this SOTE, and I respect what you are saying here and the discussions this is provoking. I wouldn't have started updating AHK Studio to v2 syntax yesterday if we didn't have this discussion. :clap:



jesswg:
jeeswg wrote:
31 Mar 2019, 08:56
- lexikos addressed the future of AHK v2, here:
AutoHotkey versions - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=57031&p=242508#p242508
Thank you for sharing that post by lexikos - it was very insightful. I appreciate all the work you have put in for this community and respect all the hard work you continue to do. I've personally learned a lot from your posts and tutorials - and am eternally grateful.
- @swagfag: I wrote a converter. The vast bulk of conversion affects whole individual lines: assignments ('var = value'), commands, directives, control flow statements (e.g. Loop). It's relatively easy to identify these lines and ignore other lines.
- Changes to functions/operators, which my converter script doesn't currently handle, I handled via custom RegExMatch/RegExReplace code. Further to that, my DllCall converter could be adapted to a general function converter. However, I converted all of my scripts without needing to write such a thing.
I looked into your post on v1 to v2 conversions and if Helgef is approving then I don't see how I wouldn't be either. It does seem like it still needs some significant work - I opted to NOT test it out because that thread seemed way too confusing (as others there expressed). I would love if you could condense your conversion script and all the libraries needed for it into one post at the top of that thread. This seems to be a massive undertaking - so nice work and keep at it!! Really cool that you are able to figure this out, as myself being quite a newb was having trouble using RegEx to convert a small selection of v1 to v2 commands.. I eventually figured it out, but can see how difficult it will be to translate everyone's differing style preferences and levels of programming skills into a consistently acceptable conversion. Excited to see how you tackle this problem (I believe in you) :)
-TL
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: When will AutoHotkey v2 become main version?

04 Apr 2019, 01:32

- @Tigerlily: Nice to see the message back.
- Btw who are these people who aren't aware of AHK v2?

- Re. error warnings. I find #Warn UseUnsetGlobal/UseUnsetLocal useful.

- Re. versions. With AHK you can easily install every version of AutoHotkey.
- Because they are just small roughly 1-2MB exe files.
- This is a major advantage of AHK.
- In the registry, you can make ahk files open with an AHK go-between script, the go-between script checks the file's path/content, and decides which AHK exe to use.

- Re. backporting. I would semi-finalise and backport the contains/in/is operators, and make available a two-way compatible Loop.
Is AHK dead? (not developed any more) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=17&t=62505&p=266650#p266650
why was LoopParse (no space) removed? - Page 4 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=41821&p=235007#p235007
- Generally speaking, everything else can be backported as custom AHK functions/classes. Exceptions are listed on my Wish List 2.0.
- People have been reaching an impasse: do I create a separate AHK v2 library, or do I make the library AHK v2 only. The operator and Loop suggestions make possible AHK v1/v2 scripts.
- Having everything backported/custom backported, allows you to convert gradually, then, when ready, you can drag-and-drop that AHK v1 script onto the AHK v2 exe. If something fails, you can go back to AHK v1 until you figure out what went wrong.

- Re. editors. Are there that many new syntax considerations?
- Other than the ability to use single quotes for assignment.
- Possibly switch statements if added. Possibly closures.

- derz00 collected my converter script/libs as a zip (just before I was going to), here:
AHK v1 to AHK v2 converter - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=36754&p=208549#p208549
- I will probably release an update in the next 2 months.
- I changed it significantly, I now use it as a function.
- There are a lot of granular settings, so that you can restrict what is converted, and do it in stages. Or just use it to tidy syntax.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 49 guests