AutoHotkey v2 Alpha Release

AutoHotkey v2

AutoHotkey v2 aims to improve the usability and convenience of the language and command set by sacrificing backward compatibility.  It has not yet reached a stable release - more compatibility-breaking changes will be made.

Downloads

 

Downloads, other links and more information.

 

Obsolete content below; refer to v2-changes.htm instead:
 

Overview of the first alpha release:

This alpha release contains most of the largest changes. Some of these changes are according to the plan, some are experimental, and a few I consider essential even though they weren't part of the plan. I don't plan to release an ANSI version, so a few of the points below are described with only the Unicode version in mind. I will outline the changes that have been made first, then the changes yet to be made.

Changes according to the plan:

• IF accepts an expression by default, even if parentheses aren't used. The traditional modes of If Var = Value, If Var <> Value, If Var > Value, etc. have been removed.
• X = Y is no longer a literal assignment.
• X `= Y is a literal assignment, for now. This form was suggested by Laszlo. [v2.0-a004-abad6fe: Removed literal assignment.]
• #AllowSameLineComments, #MaxMem, SoundGetWaveVolume and SoundSetWaveVolume have been removed.
• #NoEnv is now the mandatory default behaviour, so the directive has been removed.
• All of the commands listed in the "Eliminate legacy commands that already have a modern counterpart" section of the plan have been eliminated. Note that the L#|R# functionality of StringGetPos (mentioned by Titan) was added to InStr back in Revision 57.
• #Delimiter has been removed. (In alpha 5, #CommentFlag, #DerefChar and #EscapeChar were also removed.)
• AutoTrim and A_AutoTrim have been removed. Trim(), LTrim() and RTrim() were added back in Revision 31.
• DriveSpaceFree has become DriveGet, OutputVar, SpaceFree, Drive.
• Blanks in math operations should be consistently treated as errors. So now x += 1, y -= 1 should behave the same whether the two assignments are written on separate lines or on a single line.
• PixelSearch and PixelGetColor now use RGB instead of BGR by default. (No option is provided to use BGR.)
• A_TitleMatchMode now defaults to 2 rather than 1.

Changes based on the plan, but not precisely:

• SetFormat, A_FormatInteger and A_FormatFloat have been removed. All number to string conversions use the same format as the v1 default.
• The Transform command has been eliminated and the Deref sub-command has been promoted to a top-level command (Deref var, value).
• Characters made illegal in variable names: #, @ and $. Note that [, ] and ? were outlawed when objects were introduced in Revision 31. Additionally, variable names can no longer begin with numbers.
• Command-line args, if present, are turned into an object/array and assigned to the Args global variable.

Some legacy rules and restrictions have been removed, keeping with the theme of v2:

• Removed the special rule that = (equals) after , (comma) is assignment. For example, in x:=1, y=2 the second part will always be a comparison, not an assignment.
• Removed legacy exception for %var% in expression args. For example, return %var% is now equivalent to return (%var%) instead of return var.
• Numeric literals using scientific notation no longer require a decimal point. For example, 1e3 is equivalent to 1.0e3. I originally hoped to make 1e3 equivalent to 1000 (i.e. an integer), but it seemed difficult to do without sacrificing performance and simplicity.

Additional changes:

• Changed default SendMode to Input. This is typically the fastest and most reliable, which is why "SendMode Input" has been included in the "New AutoHotkey Script" template for quite some time. Furthermore, since Unicode support was added, most modes of Send uses SendInput() internally for any character that has no corresponding key-combination. SendInput has been the default mode for hotstrings for a while.
• Since EnvAdd and EnvSub have been removed, the date math functionality was moved to DateAdd() and DateDiff(). These are more or less equivalent to the old EnvAdd and EnvSub commands (or DateTime += Time, TimeUnits and DateTime1 -= DateTime2, TimeUnits), except that the result is returned (not assigned to the first parameter), and all parameters are required.
• If Expression, Command is now a valid If statement with same-line action, since the late IfEqual and related commands had this capability. The comma is required.
• Var declarations (using local/global/static) require := rather than =, for consistency and clarity.
• The GetKeyState command now returns 0 or 1 instead of U or D, so it is equivalent to the GetKeyState() function.
• Mouse wheel hotkeys set A_EventInfo to the delta value reported by the OS, instead of dividing it by 120 (which can lose precision, depending on the hardware and driver).
• DllCall's AStr type is now input-only, since it had very counter-intuitive restrictions as an input-output type. Specifically, the temporary buffer which was allocated to hold the Unicode->ANSI converted string was only long enough to hold the input string. (If the input string was "", the buffer was too small to receive any output value.) This change should improve performance.
• GroupAdd's Label parameter was removed. See www.autohotkey.com/forum/topic61362.html.
• #Include is now relative to the directory containing the current file, by default.
• Multi-statement comma now returns the result of its rightmost sub-statement instead of its leftmost sub-statement. For example, x := (y(), z()) is now equivalent to y(), x := z() instead of x := y(), z().

There was some discussion about changing the syntax for var derefs from %var% to $var, $var; or ${var}. Rather than making any radical changes, I've simply removed the requirement for a deref end char. That is, both of the forms demonstrated below are valid:

verb := "Hello"
subject := "World"
MsgBox [color=darkred]%verb%[/color], [color=darkred]%subject%[/color]!
MsgBox [color=darkred]%verb[/color], [color=darkred]%subject[/color]!

This also applies to double-derefs in expressions, so %func() is the same as %func%().

Finally, handling of data types has been revised for consistency and flexibility:

All integers and floating-point numbers are pure. For example, MsgBox % 0x1 and MsgBox % (0+1) are both equivalent to MsgBox 1, while MsgBox % 1.0 is equivalent to MsgBox 1.000000. Storing a number in a variable or returning it from a UDF retains its pure numeric status.

When converting a value to a boolean value, quoted numeric strings are evaluated as numbers. Unlike v1, the quoted literal string "0" is considered false.

Numeric operations are capable of working with numeric strings. For example, ("0x" Chr(65)) + 1 in v2 is 11, whereas in v1 it failed because concatenating a quoted literal string with some other value yielded a "pure not numeric" value.

Relational operators such as =, < and >= work a little differently. If one operand is a pure number and the other is - or can be converted to - a number, they are compared numerically. Otherwise, they are compared alphabetically. So for example, 54 and "530" are compared numerically, while "54" and "530" are compared alphabetically. Additionally, strings stored in variables are treated no differently from literal strings.

Type(Value) returns one of the following strings: String, Integer, Float, Object, FileObject, ComObject.

While my previous post was about changes that have been made, this one is about changes yet to be made.

At least two notable forum members have expressed a desire to remove literal assignment (var `= value) entirely. I like this idea. Do you? [v2.0-a004-abad6fe: Removed.]

The plan indicates that numerous commands should be replaced with functions. Since I plan for a future version to make commands and functions equivalent (allowing either syntax), they will probably stay as commands for now.

Chris indicated that removing Progress and SplashImage "would be quite a big reduction in code size." However, it actually appears to reduce the uncompressed exe size by only 5KB. Other reasons Chris gave to consider removing them were that their syntax is a bit clumsy and maintaining them might be a burden due to "changes in Vista and future OSes." If someone is keen to write a replacement for these, I'd consider removing them; but it doesn't seem worth much trouble. [v2.0-a013-c37f375: I decided to remove them anyway.]

Legacy commands to consider keeping (for convenience): IfWinActive, IfWinExist, IfInString, IfExist. I personally don't find IfInString all that convenient. Should it be kept? Should the others be kept? [v2.0-a004-abad6fe: Removed.]

If a future version will make it possible to call a command using function syntax, I think it would be best to rename the String commands (now rather than in that future version). For instance, StringUpper and StringReplace are inconsistent with StrLen and SubStr. I am considering simply dropping the "ing". Any objections or suggestions? [v2.0-a002-30017e5: Renamed.]

As a substitute for SetFormat (which has been removed), I've included a script function for formatting strings. Take a look in Lib\format.ahk for a description of the syntax. It is basically a mixture of .NET's String.Format function and the C runtime's format specifiers. Any comments or suggestions about the syntax are welcome. Once the syntax is finalized, I'll add a built-in function.

If Var between Low and High has not been removed. It might be at some point. [v2.0-a004-abad6fe: Replaced with between() in stdlib.]

If Var [not] contains/in value1,value2,... might be replaced with new expression operators "contains" and "in", in which case the syntax must change. All of the following might be possible:

if not var contains "value1,value2,..."
if type(n) in "Integer,Float"
x := "b" in ["a", "b", "c"]  ; x = 2
y := "red" contains "a,e,i,o,u"  ; y = "e"

Similarly, I plan to replace If Var is [not] type with a new "is" operator. Functionality would be basically the same.

Transform HTML will probably be removed, as suggested in the plan. Transform Unicode was already disabled in Unicode builds, so doesn't provide much of a barrier to eliminating the Transform command. I'm not sure what to do with Transform Deref (which isn't mentioned in the plan). [v2.0-a010-a4b2e59: Renamed "Transform Deref" to "Deref" and removed all other Transform sub-commands.]

Are there any objections to renaming URLDownloadToFile to just Download? I notice that IronAHK has a "UriDownload" function, but I wonder what the point was. My understanding is that a URL is a specific type of URI which includes information about how to locate the resource. To download something, you need to know where it is and how to get it; i.e. you need a URL. Either way, "URI" or "URL" seems unnecessary. [v2.0-a015-7e81e17: Renamed.]

SplashTextOff/SplashTextOn: PhiLho suggests eliminating the fact that the option (On/Off) is part of the command name. Perhaps SplashTextOn can be renamed to SplashText, and omitting all parameters can turn it off - like the ToolTip command. [v2.0-a013-c37f375: Removed SplashTextOff/On. Should be easy to write a replacement with Gui.]

I've wondered for a while why we have commands like WinSet and WinGet with numerous sub-commands, then separate commands like WinGetClass and WinSetTitle. I think that making these consistent would be an improvement, whether that means a couple commands with many sub-commands, many individual commands, or both (e.g. have WinGetTitle, var and WinGet, var, Title).

I plan to change StringSplit and RegExMatch to output an array (an object) instead of a pseudo-array (a bunch of variables). RegExMatch could potentially provide both the position and value of each capturing sub-pattern.

Chris suggested that the Loop command (and sub-commands) might benefit from parameter reordering and disambiguation. I'm not sure how the parameters should be reordered, but I think disambiguation would require two new sub-commands: Loop File and Loop Reg. Alternatively, I've considered Loop, LoopFile, LoopParse, LoopRead and LoopReg. [v2.0-a004-abad6fe: Split Loop into Loop, LoopFiles, LoopReg, LoopRead and LoopParse.]

I would like to rename WinMenuSelectItem to something shorter. Perhaps just drop "Item". I don't see much benefit in changing this command to accept an array vs a list of parameters, as suggested in the plan. [v2.0-a015-7e81e17: Renamed.]

Chris suggested to redesign InputBox's parameter list to be a "flex-list", which I think would be something like this:

InputBox, OutputVar [, Title, Prompt, Hide w%Width h%Height x%X y%Y t%Timeout, Default]

On the other hand, someone (probably majkinetor) mentioned that InputBox would benefit from named parameter support:

OutputVar := InputBox(Prompt: "Enter some stuff", Default: "foobar", Width: 500, Height: 300)

It should be feasible to support both. However, a flex-list could be implemented much sooner.

As you may have noticed, I prefer the new style of omitting the deref ending character (%). Of course there are some cases where the ending character is required, such as when a literal alphanumeric character immediately follows the deref. Additionally, the following syntax is reserved for future use:

MsgBox var is %hex[color=red]([/color]var)

The idea is that expressions may be embedded in a non-expression arg by writing %func(params) or %(expression). I believe this will require extensive changes to implement properly, so it probably won't be implemented in v2.0. However, I will add support for the simplest case, %(var), if there's enough demand for it.

On that note - I would like to support variable derefs inside quoted literal strings. There are a number of different possibilities:
[*:2m3aoe7u]'%var' could contain a variable deref while "%var" is purely literal, as in v1. There's a certain logic to this: doubly-quoted strings are "twice as literal" as singly-quoted strings. [*:2m3aoe7u]Opposite to the above, "%var" could contain a variable deref while '%var' is purely literal. I think that Perl and Bash scripts use this convention. [*:2m3aoe7u]A meta-character (such as the deref character itself) could be prepended to the literal string to enable variable derefs. For example, %"the value of %key is %value". [*:2m3aoe7u]Both types of quote marks could be equivalent, for convenience, and both could allow variable derefs. [v2.0-a003-9a480e6: Quoted strings of either type may contain variable references.]

There could be some way to "escape" all meta-characters in a string, such as r"..." (Python), @"..." (C#) or `"..." (escape char applied to opening quote mark).

Additionally, there have been requests to support using the usual escape character as a means to escape double quote marks in literal strings. For example, "this is a `"quote`"". Some editors which support AutoHotkey syntax highlighting act as though this is already valid, but it isn't. [v2.0-a003-9a480e6: Done.]

I would like to replace the syntax for continuation sections so that it does not conflict with parenthesized expressions (such as (x = y) ? foo() : bar()). Unfortunately, I have not come up with any "good" ideas. [v1.1.01/v2.0-a013: The presence of ")" now causes the line to be interpreted as an expression.]

Laszlo suggested commands which now accept input vars should instead allow any arbitrary expression. I would like to implement this, but at the moment it doesn't seem feasible. I will keep it in mind for the future.

So far I've avoided removing auto-concat or changing the auto-concat rules, but that may change, especially if stricter syntax checking is implemented. I know there are some users who oppose the removal of auto-concat, but I think allowing variable derefs (and possibly nested expressions) in quoted strings may make up for that.

Currently the ".ahk" extension is still used for Lib files and to find the default script. If there is demand, I might change it to ".ah2" as suggested in the plan.

Now I think I've covered everything in the v2 plan... but there's more - ideas I've had while working on v2.

Window groups could be improved to make exclusions more intuitive – e.g. GroupExclude G, title would combine with existing rules to exclude all windows with “title” in the title, whereas GroupAdd G,,,, title currently adds all windows to the group, except those with “title” in the title. Furthermore, supporting ahk_class, ahk_id, etc. in the exclusions could prove very useful.

Should the script’s working directory start as A_ScriptDir? (This seems to be desirable, since the "New AutoHotkey Script" template includes SetWorkingDir %A_ScriptDir%.) A_InitialWorkingDir or similar can be added for retrieving the working dir set by whatever launched the script. My initial thought was A_StartupDir, but that may be confused with A_Startup (the Start menu Startup folder). [v2.0-a002-30017e5: Done.]

Should octal and/or binary numeric literals be supported? Octal can be supported automatically (as 0777) by removing a check (which is currently in place just to prevent numbers like 0777 from being interpreted as octal), or with a little extra work, as 0o777. Binary could be supported as 0b0110. These custom prefixes might affect performance, at least for scripts which convert strings to numbers frequently. Alternatively, they could be supported exclusively as literals in expressions, at load-time only, so not affecting run-time performance. Note that since the format of numeric literals is no longer retained, there's currently no meaning to the leading zeros in something like 0000123.

Should x:= with no expression be tolerated? Currently it is (as in v1), but if it is combined with another expression (such as y:=1, x:=), it is an error (it causes stack underflow). [v2.0-a002-30017e5: Expression now required.]

Should the *deref operator be removed? It is faster than NumGet for retrieving a single byte, but much slower retrieving a two-byte or larger value. It is also much more cryptic.

While benchmarking for the point above, this occurred to me: Since integers and numeric strings can easily be distinguished now, I think that NumGet(ptr) and NumPut(n, ptr) should use the integer contained within ptr as the target address, rather than the address of ptr's internal string buffer. This is especially true since &var_containing_integer is currently treated as an error. However, that might be allowed in future, e.g. for use as an 8-byte buffer for small structs, such as POINT. (An additional bonus would be that you could use both bitwise operations and NumGet/NumPut to manipulate the number/struct.) [v2.0-a002-30017e5: Changed.]

Should SubStr(str, -1) extract the last two characters of str as it does now, or only the last character? I have to stop and think every time I use it; I think that -1 extracting only the last character (-2 extracting the last two, and so on) would be much more intuitive, especially given that SubStr and InStr use one-based positions. (For InStr it already makes sense: -1 means search right-to-left, omitting the last character from the search.) [v2.0-a004-abad6fe: Changed SubStr, RegExMatch and RegExReplace.]

That is sweet! Would be so awesome I don't understand all of the changes, but from what I understand, it's definitely in-the-right-direction.

Removing "var = hello" is probably the largest controversy. I support removing it. I remember learning the different ways of assigning variables was one of the largest sources of frustration when I started using AHK, and now I just assign in the "correct" way, var := "hello".

As for allowing change in the syntax of variables ($var instead of %var%) I support the changes. I imagine alot of people would be good off by using another syntax for variables, since %% is quite unique for Autohotkey. Might be a bit confusion around if people start defining their own variable derefs just because they can, but %var% doesn't really look pretty and intuitive, so I support the change.

Removing SplashImage is something I would be for, just because it's clumsy. That is, if we could get a good replacement. I find it unintuitive that Splash commands need to be turned on and then off, and that SplashText and SplashImage are two different commands. A "Splash, Title, Text, Duration, Options, Image" would be better in my opinion, if it was backed up with solid coding. Options could be specified as On/Off to maintain that functionability.

I might return to this topic for more discussion.

I just want to say, thanks alot for the work and effort put into this, this is happy news!

Wow, I did not know you were this far with V2 already!

I have read through everything, and as expected, I agree with some points while I don't like others. I hope that I will find the time to provide detailed comments on them later.

For now, just some general opinions:

As I am mainly working on a single larger program in AHK_L (~20k lines), I am wondering if, how and when I should start the transition to V2. It's obviously not now, but it's probably useful to keep the changes in mind and drop legacy commands that will be removed. Is there a plan to add specific warnings/error messages about some of the old features to ease conversion? IA does something similar I think by providing some auto-conversion and warnings IIRC.

I would like to see the functions get more tied to the object syntax, i.e. have the string functions be accessible as methods on any string by default, without defining the string base manually. This would allow syntax like String.Len(). The same probably goes for GUIs (see the thread about GUI and Control objects) and possibly HWNDs, but I'm not sure if this is feasible to implement.

I like the idea of replacing commands with functions, or atleast making them equivalent. Right now I'm still using polyethenes function library for this.

All in all, I would vote for getting rid of everything that seems irregular. There are many exceptions and syntax ambiguities that can be really confusing, atleast they were to me when I started learning this language.

I also suggest getting rid of default listviews and treeviews (there are possibly other examples). Specifying the control in the function is better for reducing issues with threading in which the default control changes.

Keep up the good work, I'm really looking forward to it!

Characters made illegal in variable names: non-ASCII characters, #, @ and $. Note that [, ] and ? were outlawed when objects were introduced in Revision 31. I find the easiest way to describe the new restrictions is with a regex: i)^[a-z_][a-z_0-9]*$

for me, this is a dissapointment. it is very attractive that old version (your unicode ahkL) allow to use my own languages characters as variable (türkish), is this absolutely necessary? if not, please let it in old state!! thanks and good works.. :roll:

It's great! But the debug feather doesn't work now? IMHO support the debug will help us know what is exactly going! :lol:

Alright, time to reply:

However, #CommentFlag, #DerefChar and #EscapeChar have not.

Any plans on removing them? (especially #CommentFlag and #EscapeChar)
The ability to change syntax features in a script is a pain in the backside for IDEs to handle.

Characters made illegal in variable names: non-ASCII characters, #, @ and $.

I disagree with outlawing non-ASCII characters. Remember that not everyone speaks English, and some people like using their mother tongue when programming.

At least two notable forum members have expressed a desire to remove literal assignment (var `= value) entirely. I like this idea. Do you?

It definitely has to go. It only creates confusion in newbies.

Chris indicated that removing Progress and SplashImage "would be quite a big reduction in code size." However, it actually appears to reduce the uncompressed exe size by only 5KB. Other reasons Chris gave to consider removing them were that their syntax is a bit clumsy and maintaining them might be a burden due to "changes in Vista and future OSes." If someone is keen to write a replacement for these, I'd consider removing them; but it doesn't seem worth much trouble.

Remove it, please. You can already do that using GUIs. Besides, the Progress Dialog looks shoddy compared to the built-in Windows progress dialogs, which are available programmatically.

If a future version will make it possible to call a command using function syntax, I think it would be best to rename the String commands (now rather than in that future version). For instance, StringUpper and StringReplace are inconsistent with StrLen and SubStr. I am considering simply dropping the "ing". Any objections or suggestions?

I agree.

If Var between Low and High has not been removed. It might be at some point.

Remove it, it's redundant. Or instead introduce a function: Between(Value, LowerBound, UpperBound)

I'm not sure what to do with Transform Deref (which isn't mentioned in the plan).

I would replace it with a more general Eval() function.

Are there any objections to renaming URLDownloadToFile to just Download?

None. URLDownloadToFile is just cumbersome to type (and ugly) compared to Download.

I plan to change StringSplit and RegExMatch to output an array (an object) instead of a pseudo-array (a bunch of variables). RegExMatch could potentially provide both the position and value of each capturing sub-pattern.

Yes, please.

Chris suggested that the Loop command (and sub-commands) might benefit from parameter reordering and disambiguation. I'm not sure how the parameters should be reordered, but I think disambiguation would require two new sub-commands: Loop File and Loop Reg. Alternatively, I've considered Loop, LoopFile, LoopParse, LoopRead and LoopReg.

Good. It is definitely better for IDEs to interpret.

Additionally, there have been requests to support using the usual escape character as a means to escape double quote marks in literal strings. For example, "this is a `"quote`"". Some editors which support AutoHotkey syntax highlighting act as though this is already valid, but it isn't.

That's a good idea. Duplicating the quotes is cumbersome, error-prone and hard to read:

MsgBox % """" someVar """"

I would like to replace the syntax for continuation sections so that it does not conflict with parenthesized expressions (such as (x = y) ? foo() : bar()). Unfortunately, I have not come up with any "good" ideas.

What about using (< and >) or similar?

So far I've avoided removing auto-concat or changing the auto-concat rules, but that may change, especially if stricter syntax checking is implemented. I know there are some users who oppose the removal of auto-concat, but I think allowing variable derefs (and possibly nested expressions) in quoted strings may make up for that.

Auto-concat is one of my favourite features of AHK, so please don't remove it. If in-string variable references are implemented, it's OK; but still, the concat operator is ugly:

MsgBox % var1 . var2 . var3 . var4

I might change it to ".ah2" as suggested in the plan.

Yeah, that seems sensible.

Should the script’s working directory start as A_ScriptDir? (This seems to be desirable, since the "New AutoHotkey Script" template includes SetWorkingDir %A_ScriptDir%.) A_InitialWorkingDir or similar can be added for retrieving the working dir set by whatever launched the script. My initial thought was A_StartupDir, but that may be confused with A_Startup (the Start menu Startup folder).

Yes. A_InitialWorkingDir seems good.

Should octal and/or binary numeric literals be supported?

Why do you need octal numbers? I understand the need for binary literals (the 0b syntax seems nice), but octal literals?

Should x:= with no expression be tolerated?

No. Again, it's a gotcha.

Should the *deref operator be removed?

Yes. Perhaps native Struct support could be implemented. As for the deref operator, its effect could even be changed to do something (useful) completely different.

I think that NumGet(ptr) and NumPut(n, ptr) should use the integer contained within ptr as the target address, rather than the address of ptr's internal string buffer

Yes! The current behaviour is a gotcha.

----

Oh, and this behaviour is counterintuitive:

array := ["Hello, world"]
var := "w1w"
MsgBox % array[SubStr(var, 2, 1)] ; blank MsgBox

First of all, thank you! I have been wanting this for a long time, but didn't think it was this close.

Alright, time to reply: ...

I agree with everything you said, but I have a few more comments.

Legacy commands to consider keeping (for convenience): IfWinActive, IfWinExist, IfInString, IfExist. I personally don't find IfInString all that convenient. Should it be kept? Should the others be kept?

I would get rid of IfInString. The others sometimes seem more natural than using a function, making them easier for new users. I would keep those.

If a future version will make it possible to call a command using function syntax, I think it would be best to rename the String commands (now rather than in that future version). For instance, StringUpper and StringReplace are inconsistent with StrLen and SubStr. I am considering simply dropping the "ing". Any objections or suggestions?

How does StrSub for StringSubstitute sound? In effort of keeping them 6 letters. (Idea taken from Lua's gsub function)

If Var between Low and High has not been removed. It might be at some point

I would remove it. I stay away from this because I have no idea if its inclusive or exclusive. You could always be one of the first to support inequalities in a programing language :wink:

I plan to change StringSplit and RegExMatch to output an array (an object) instead of a pseudo-array (a bunch of variables). RegExMatch could potentially provide both the position and value of each capturing sub-pattern.

This is just about the top of my wish list.

Chris suggested to redesign InputBox's parameter list to be a "flex-list", which I think would be something like this:
InputBox, OutputVar [, Title, Prompt, Hide w%Width h%Height x%X y%Y t%Timeout, Default]
On the other hand, someone (probably majkinetor) mentioned that InputBox would benefit from named parameter support:
OutputVar := InputBox(Prompt: "Enter some stuff", Default: "foobar", Width: 500, Height: 300)
It should be feasible to support both. However, a flex-list could be implemented much sooner

If you want to do both, it would be nice. However, I don't think we really need both.

There was some discussion about changing the syntax for var derefs from %var% to $var, $var; or ${var}. Rather than making any radical changes, I've simply removed the requirement for a deref end char. That is, all of the following are valid:

I can't think of a consistant way for a single deref character to work. There have to be restrictions on the deref characters such as: it can't be a valid variable symbol, can't be an escape character, and can't be a white space. Also if we are using it in an expression, it can't be )(][/*-,><?" and others would be confusing to parse: .:! On the other hand, I don't see why it couldn't be a non-ANSI Unicode character. Thoughts?

Anyway, thanks for all the hard work! I'm on linux atm, but I'm going to Windows 7 to test this out. I'll let you know if I find any bugs :wink:

Edit: One more note, I think PixelGetColor could be replaced with a function all together. The advantage is that's how most would use it, only once, for example an if statement. The downside is consistency with PixelSearch and ImageSearch which are commands.

It appears that Windows ME and earlier are no longer supported. What is the oldest OS supported (XP)?

In my opinion one of the strong points of AHK V1 is its documentation (help file). It is very good with lots of examples. I realize this is an alpha release but, is there an updated (V2) help file available yet? If not, when can we expect one? Not trying to be cheeky (pushy) just curious as to the time-line.

Is this AHK_L with all the good stuff that it brought or something else?

dmatch

IMHO, most of changes are OK. The following changes/plans are not good:
• characters made illegal in variable names: non-ASCII characters, #, @ and $
• removing auto-concat
• X `= Y is a literal assignment

But I must admit that I'm very unsure what is the future; AutoHotkey v2? IronAHK? Stick to AHK_L? Something else? What to choose? I'm starting to feel lost... Too much versions and forks of AutoHotkey, different syntax, different rules = bad.

Btw, who will write a script that will transform all those great AutoHotkey v1 codes to AutoHotkey v2? Mission impossible?

In my opinion one of the strong points of AHK V1 is its documentation (help file). It is very good with lots of examples. I realize this is an alpha release but, is there an updated (V2) help file available yet? If not, when can we expect one? Not trying to be cheeky (pushy) just curious as to the time-line.

Well this is just an alpha release. I think getting the features down is more important than documenting them right now. It would just be silly to write documentation after every little change. I'm sure as with all AHK releases before documentation will come around for the actual release (not to speak for Lexikos)

Is this AHK_L with all the good stuff that it brought or something else?

Yes. This is the next step for AHK. It uses AHK_L as a base and expands on that. There's been talk about AutoHotkey v2 for years, before Lexikos's builds and now were getting it.

If Var [not] contains/in value1,value2,... might be replaced with new expression operators "contains" and "in", in which case the syntax must change.

Wouldn't it be a little more convenient to just convert them to functions?

if !Contains(var,"value1,value2,...")
if IsType(n,"Integer,Float")
x := In("b",["a", "b", "c"])  ; x = 2
y := Contains("red","a,e,i,o,u")  ; y = "e"

And it would also be nice if a parameter to specify a delimiter other than comma could be added (or, possibly delimiter auto-detection).

I think if [var] between would also be a nice candidate to support as a function, Between().

And have you considered adding And() and Or() functions like in Excel? I think functions like these would save space and improve readability in code, IMO.

If Expression, Command is now a valid If statement with same-line action, since the late IfEqual and related commands had this capability.

This is a good thing.

And since you had pondered using the same syntax style that is used in the RegExReplace function for dereferencing (${var}) and that syntax supports Upper/Lower/Title conversion in RegExReplace, would it be possible to make the blocks a special case deref for supporting those conversions?

verb := "Hello"
subject := "World"
MsgBox %verb%, %subject%! ; Hello, World!
MsgBox %L{verb}, %U{subject}! ; hello, WORLD!
#DerefChar $
MsgBox $U{verb}, $subject! ; HELLO, World!
MsgBox $verb$, $subject$!

remove literal assignment (var `= value) entirely. I like this idea. Do you?

I'm not sure what to do with Transform Deref

I would like to support variable derefs inside quoted literal strings. There are a number of different possibilities

I agree with removing (var `= value), and also removing (Transform Deref), and instead replacing its functionality with variable derefs inside quoted literal strings.

@Fincs: While I wholeheartedly support having an Eval() as a general text-to expression evaluation function, I think it wouldn't be a good replacement for (Transform, Deref) or version 1's (var = value)

Legacy commands to consider keeping (for convenience): IfWinActive, IfWinExist, IfInString, IfExist. I personally don't find IfInString all that convenient. Should it be kept? Should the others be kept?

I say take them all to the chopping block. They all have direct (if expression) equivalents, and this would keep it simple and consolidate the command and syntax that new people need to learn.

If Var [not] contains/in value1,value2,... might be replaced with new expression operators "contains" and "in", in which case the syntax must change.

I completely agree with new expression operators. This way there is only one type of if: (if expression). Simple and straightforward.

I also think they should exclusively work with objects or arrays, i.e. y := "red" in "a,b,c,d" would compare to the single complete string "a,b,c,d" and not split it. We have objects and arrays now, there's no need to introduce additional syntax to handle what they are designed to offer.


I support changing loop syntax. I like Fincs' point that it would be much easier for syntax highlighting to handle.

Should x:= with no expression be tolerated?

No it should not, I agree with Fincs.

I like the idea of changing SubStr -1 start index to retrieve the last, not second to last, character.

I also support removing "ing" from the string commands, in preparation for using them as functions and merging their naming conventions with our current string functions.

Should the *deref operator be removed?

Ok, how about this: Yes, remove it.
BUT when the *deref NumGet equivalent is found in an expression, {NumGet(deref,0,"chr") I think} translate it behind the scenes (i.e. unknown to the user) to use the faster method that *deref uses. This could even be put off and done at a later time.
This both simplifies and consolidates the syntax, but does not impose any performance hits compared to v1.

Wow there's still a lot. But that's my two cents for now.

Sinkfaze: No, I do NOT like the idea of converting every bit of our expression syntax into a bunch of functions.

It's especially a horrible idea because it would bypass the short-circuit boolean evaluation that can be very important in expressions.

Characters made illegal in variable names: non-ASCII characters, #, @ and $

Ouch .

Rest, i tend to agree with fincs a lot.

Escaping a quote `" is a great idea.