I would recommend holding off on switching to v2 for any serious scripts, at least until the first non-alpha release. Just keep in mind the changes and avoid literal assignments, traditional IFs and other legacy commands. For a more exhaustive list of changes, see the
github commit history. I do not plan to add any warning messages to ease the transition, but I do plan to write a conversion script.
I would like to see the functions get more tied to the object syntax,
I'd like to defer this and other ideas which won't break compatibility until after the first non-alpha release. In this case I think it could even be safely added to v1.1.
I also suggest getting rid of default listviews and treeviews (there are possibly other examples).
I can see your point, but I think that the current functions are convenient, especially for scripts that only have one ListView. Those might be the most common.
it is very attractive that old version (your unicode ahkL) allow to use my own languages characters as variable (türkish)
Thank you for your feedback. I may have undervalued that capability. I think most of the languages I've used heavily have the same restrictions as v2-a001, but I see Java and JavaScript aren't as restrictive. Non-ASCII characters are prone to encoding problems, but I suppose that the users who benefit most from non-ASCII variable names are the ones who will have to deal with that. I'll relax the rules to allow non-ASCII characters, unless someone comes up with a compelling reason not to.
But the debug feather doesn't work now?
I think something was lost in translation. Would you care to restate your question?
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.
If there's no demand to keep them, I will remove them at some point. For now, #DerefChar is mainly kept to allow experimentation with the deref syntax.
Remove [Progress and SplashImage], please. You can already do that using GUIs.
I'd like to know if anyone values these commands. I suppose the easiest way to find out is to remove them, and wait for the complaints.
Or instead introduce a function: Between(Value, LowerBound, UpperBound)
I prefer the idea of converting it to two checks: >= and <=.
I would replace it with a more general Eval() function.
That isn't going to happen for v2. It also wouldn't be as convenient for simply dereferencing variables. Maybe format() and format_v() will be sufficient substitutes for Transform Deref. If we provide some means to retrieve local or global variables in an array (which I believe has been requested in one form or another), the array can be passed to format_v. Similarly, you can write an object which wraps EnvGet, and pass that to format_v.
What about using (< and >) or similar?
I kind of like
your original idea,
(| and
|). I think that either would be okay; since both "<" and "|" are ordinarily binary operators, there's no ambiguity with expressions.
Auto-concat is one of my favourite features of AHK,
It seems to be a love/hate kind of feature. The only problems I have with the current concat operator are the white-space requirement and the ambiguity with object syntax.
Why do you need octal numbers? I understand the need for binary literals
I don't on either account, which is why I ask. If binary is supported but octal is not, the number-parsing functions then needs to check IsHex (to avoid treating 0777 as octal) and IsBin every time. 0o777 was just an idea from using SpeedCrunch, mentioned for consistency with 0xFFF and 0b111.
Oh, and [the behaviour of numeric strings as keys in objects] is counterintuitive:
Yes, I fell into that trap myself, shortly after setting it up.
My thinking was that numeric strings allow one to bypass the array-like behaviour of Insert and Remove, but maybe that's just another case for implementing a dedicated array type (and removing the array-like behaviour from objects).
How does StrSub for StringSubstitute sound?
Are you talking about StringReplace? The fact that I even have to ask is a good reason not to use that name. Having StrSub and SubStr would be far too confusing.
I can't think of a consistant way for a single deref character to work.
I'm not sure what you mean. I can guess you mean that an ending character or something like {} must be supported, to which I'd agree. However, it's only necessary when the next character after the deref is valid in a variable name. For expressions, it only applies to double-derefs and dynamic function calls, like
%prefix%_handler(). I think that
%(expression) is the most intuitive and flexible solution.
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.
There are restrictions. Some are imposed specifically by #DerefChar and some are present due to the way derefs and expressions are parsed. For instance, it can't be any character which forms an expression operator or any character which is valid in a variable name. %, $, @, #, ' and \ are probably the only ones that can be used globally at the moment.
One more note, I think PixelGetColor could be replaced with a function all together.
As I noted, I won't be replacing any commands with functions at this stage. Eventually they will be interchangeable.
It appears that Windows ME and earlier are no longer supported.
Microsoft Visual C++ 2010 officially does not support targetting any platform older than Windows XP SP2. However, AutoHotkey_L is patched to work on Windows 2000 and Windows XP SP0/SP1. I've been told that Windows 2000 requires certain updates which are only available for English versions of the OS.
If not, when can we expect [an updated help file]?
Expect an updated help file by the first non-alpha release. Nothing is final yet, so keeping the documentation up to date would be a burden - unless someone else volunteers.
The following changes/plans are not good:
You are wrong.
Okay, so it's a matter of perspective. You haven't explained yours. In particular, I want to know: Are you unhappy that #, @ and $ have been outlawed in variable names, or just non-ASCII characters? Are you unhappy with = becoming exclusively a comparison, or with `= as the current form of literal assignment? Keeping = as literal assignment goes against the very purpose of v2.
Wouldn't it be a little more convenient to just convert them to functions?
I personally think they don't have enough value as functions to be built-in. However, I could remove them and let
you convert them to functions.
I think functions like [And() and Or()] would save space and improve readability in code, IMO.
...
And there's no reason short-circuit evaluation could not be built into an And() or Or() function if such functions were desired.
I don't see how they would save space, and I disagree about readability. To support short-circuit evaluation, they would need to be internally handled as operators, which would be counter-intuitive and not worth the added complexity.
And since you had pondered using the same syntax style that is used in the RegExReplace function for dereferencing (${var})
Actually,
I wasn't pondering that. I merely mentioned that it was discussed. Using the same syntax as RegExReplace could be misleading, and inconvenient if var derefs are supported in strings. More to the point,
%(var) seems like a better choice to me.
would it be possible to make the blocks a special case deref for supporting [UPPER/lower/Title case conversions] conversions?
I don't believe it would be worth the added complexity. With my earlier proposals, this would be possible:
MsgBox [color=darkred]%StrLower(verb)[/color], [color=darkred]%StrUpper(subject)[/color]! ; hello, WORLD!
I agree with [...] removing (Transform Deref), and instead replacing its functionality with variable derefs inside quoted literal strings.
I think you're misunderstanding the purpose of Transform Deref. This can't be done with variable substitution in literal strings:
Transform value, Deref, % Chr(37) . ComputeVariableName()
To further clarify, the following would be exactly equivalent at run-time:
x := "y is %y"
x := "y is " . y
i.e. y := "red" in "a,b,c,d" would compare to the single complete string "a,b,c,d" and not split it.
Are you suggesting that it should be equivalent to
InStr("a,b,c,d", "red")? That might be convenient.
We have objects and arrays now, there's no need to introduce additional syntax to handle what they are designed to offer.
By the same token, the functionality of "in" and "contains" could be implemented as methods of the array object. There's no real need for additional syntax.
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.
My opinion is that it wouldn't be worth the added complexity. The performance difference isn't very significant, and the deref operator is probably rarely used to begin with.
i like the option to use both RGB or BGR and use it regularly
I'll consider adding a "BGR" option, but is there some reason you can't write a simple conversion function to be used like
PixelSearch, x, y, ..., % RGB(bgr_value)? The other commands which accept colour values don't support a BGR option.