Reconsideration request? Topic is solved

Discuss the future of the AutoHotkey language
ltlistener_ftcaller

Reconsideration request?

11 Nov 2017, 10:57

@Lexikos, I really appreciate all your work over the years on AHK. For macros and personal productivity use cases, I've done more coding in AHK than any other language... leaving batch scripts, VBA, ad hoc python scripts, etc. by the wayside years ago. However, earlier this year, when it was decided to eliminate command syntax (or more accurately, the unquoted string with %deref% embedded), as well as moving a lot more of the quick-and-dirty GUI commands to a more structured syntax, I slowly found myself not using the language as much.

I realize I'm a sample size of one, but I have two primary use cases for AHK: (1) quick batch file replacement or text manipulation scripts (a lot of them, with a lot of literals) and (2) a more robust 5000-line personal macro script that runs at all times. I typically used unquoted command syntax with %var% derefs and quick-and-dirty gui creation a lot for the former case, and tried to use the more structured language features for the latter. In fact, I changed all of the personal macro script code to v2 a couple of years ago, because of single-quote strings, same-line ifs (now eliminated), derefs in string literals (now eliminated), and a few other features, others of which are now gone or different -- as is to be expected with an alpha. I realize too that a lot of what's feasible has been constrained by the fact that you inherited code that didn't come with a proper lexer/parser, etc.... and you've done a really amazing job adding a full object syntax and so much more... almost single-handedly making AHK nearly everything it is today.

I used to think AHK was unique because it had this cool dual existence -- part quick-and-dirty, but also part structured where you needed it to be. And you could share your function libraries between the two worlds. If everything moves toward exclusively structured, it seems to me that there are other more structured languages (particularly those with functional programming features and stronger library support) that I would move to. In fact, because I've already been using Kotlin a lot recently for Android work, I've since written a C-based keyboard hook that works with Kotlin to duplicate much of my AHK macro functionality.

TL;DR: Before I get too far down that path, I wanted to ask if there is any chance of reconsidering the unquoted string decision??? Or at least allowing for quick "string literal $interpolation or ${embedded + expressions} or what not" (like kotlin or maybe like python or ruby)? I think at one time you even used to allow "string %deref% in literals" but I think that's gone too. Like I said earlier, I very much respect your great work on AHK. That's part of why I wanted to ask the question before moving my code out of the language.

I definitely appreciate your time and consideration.
guest3456
Posts: 2075
Joined: 09 Oct 2013, 10:31

Re: Reconsideration request?

11 Nov 2017, 17:52

i have no idea why the % derefs within quoted strings was removed. that was one of my favorite features in v2.

Code: [Select all] [Download] GeSHi © Codebox Plus

MsgBox("hello world my name is %name%")

User avatar
jeeswg
Posts: 2961
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

11 Nov 2017, 18:16

- Deref and the like went from pride of place to being completely removed. If the idea was to discourage their use and to promote expression syntax, that's fine, but I believe that the concept is still very beneficial and should hopefully live on.
- I would very much like this to be possible in both AHK v1 and v2, with an option to specify the delimiter characters:

Code: [Select all] [Download] GeSHi © Codebox Plus

MsgBox(Deref("hello world my name is %name%"))
MsgBox(Deref("hello world my name is {name}"))
MsgBox(Deref("hello world my name is %obj.key%"))
MsgBox(Deref("hello world my name is {obj.key}"))

Users can already create custom Deref functions to handle global variables (not pretty) or local/global objects (pretty workable) as above, but that cannot handle local variables in functions.
- I discuss all my recommended solutions for string issues here:
AHK v2 and strings - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=36833

- Single-line if workarounds:

Code: [Select all] [Download] GeSHi © Codebox Plus

(vCond = 1) ? Func1() : Func2()

;these two are equivalent:
(vCond = 1) ? Func1() : 0
(vCond = 1) && Func1()

Cheers, thanks for your comments ltlistener_ftcaller.
ltlistener_ftcaller

Re: Reconsideration request?  Topic is solved

11 Nov 2017, 19:56

Thanks for the thoughts. @guest3456, I do think embedded string deref/interpolation was my favorite feature of v2 as well. If I'm not mistaken, I think for a time you could even embed any expression... but I can't remember if the extra surrounding parentheses were required:

Code: [Select all] [Download] GeSHi © Codebox Plus

MsgBox("hello world my name is %(nameformat(name.first, name.last))%")

I only raised it because getting that back might ease the blow of the command/unquoted syntax going away completely. Don't get me wrong, I would still like the command syntax back.

On certain types of quickie batch files, which might include a Run line with quotes/apostrophes/etc. and maybe a lot of params also in quotes, it was so nice to be able to just bang out the following:

Code: [Select all] [Download] GeSHi © Codebox Plus

Run, "file with spaces and wouldn't rule out apostrophes.txt" /s="\my dir" /t="\some other dir"

I know there are now workarounds, but I think it's still not as quick/legible as before. Also, in fairness, escaping commas with backtick was sometimes required too. Just for me, not quite as often...

Also, @jeeswg, with respect to same-line if, your ternary workaround is where I ended too. It's just not as readable, especially starting a code line, and it does require that initial parenthesis and an else (where you may, as you say, just type :0). I suppose another workaround could be allowing same line braces { }, which would be nice everywhere, if possible:

Code: [Select all] [Download] GeSHi © Codebox Plus

if arg == 1 { return '' }
; or
swap(byref a, byref b) { h:=a, a:=b, b:=h }

I know there are purists who like to see this sort of thing on 2-3 (or sometimes up to 6 lines without OTB or multi-statement), which for me just isn't as readable. At least for me, the gist of a lot of idioms is clearer this way, especially since I've got a bunch of wanna-be "one-liners" that make up a good part of my function library. Anyhow, a lot of languages allow this, as you all know.

While on that topic of abbreviating unnecessary (imho) multi-lines, it would be great to one day have the Elvis ?: operator. (I'm sure it's a low-priority feature request somewhere on some list, and I know there isn't a large enough community for nice-to-haves at this point.) In Kotlin, for example, it's used not as an omitted second operand in a ternary expression (a la C), but as a distinct operator meaning "if null then instead use following value". Perhaps in AHK it could be applied to empty "" in a parallel way. I find myself doing these checks all the time:

Code: [Select all] [Download] GeSHi © Codebox Plus

val := (option1 != "") ? option1 : (option2 != "") ? option2 : default
; ignoring, for the moment, its 10-line multi-line if/else equivalent :)
; could instead become as dead simple as:
val := option1 ?: option2 ?: default
; BOOM! ...and you still get short-circuit evaluation... DOUBLE BOOM!

Yes, I know I can (and do) sometimes use a function like first_nonempty(option1, option2, default), but you lose short-circuit when you do that.

Anyhow, just to present a more balanced view, I definitely think AHK has lots of syntactic sugar points that make it even more efficient/terse than other languages, in certain situations. I love the syntax sugar of extending ("").base some places. I love that assignments return a value and can be mixed into an expression. I love the multi-statement comma. I love that byref is possible. For scripting, I love dynamic types.

...And maybe, just maybe, @lexikos had other and greater possibilities in mind when he eliminated string derefs. Watching his comments/releases over the past many years, I know he gives a lot of thought/planning to his decisions. That's why I wanted to better understand the thought around this before making any decisions about converting the remainder of my code base. Thanks again, guys, for the time and thoughts.
ltlistener_ftcaller

Re: Reconsideration request?

12 Nov 2017, 07:27

P.S. As I was editing AHK code last night, thought a little more about Elvis operator application to AHK (although it's a little off-topic for this post)... I think the falsey nature of "" (and 0) combined with the fact that and/or return the truthy/falsey value rather than 1/0 does help a little. I often find myself getting the first non-empty with option1 or option2 or default where I might have done option1 ?: option2 ?: default, rather than writing out the ternary. That's just as good as Elvis (and maybe better for clarity), EXCEPT it only works when the valid values are definitely non-zero, since 0 is falsey just like "". In my rough count of references last night, that's only about half the time for me. The rest of the time, 0 is in play, and the longer ternary is the solution. Anyhow, just a clarification... a nice-to-have to be sure, but there are bigger fish to fry... like the original topic of my post (optional old-style command syntax, string interpolation, etc.)
User avatar
jeeswg
Posts: 2961
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

12 Nov 2017, 07:42

ltlistener_ftcaller wrote:On certain types of quickie batch files, which might include a Run line with quotes/apostrophes/etc. and maybe a lot of params also in quotes, it was so nice to be able to just bang out the following:

...

Also, in fairness, escaping commas with backtick was sometimes required too. Just for me, not quite as often...

Great point, I was hoping with my Verbatim idea to solve both these problems. I.e. treat text literally, and specify text in the Options parameter to make it a little less literal, in useful ways, effectively a one-line continuation section.

ltlistener_ftcaller wrote:Anyhow, just to present a more balanced view, I definitely think AHK has lots of syntactic sugar points that make it even more efficient/terse than other languages, in certain situations.

Great point.

ltlistener_ftcaller wrote:...And maybe, just maybe, @lexikos had other and greater possibilities in mind when he eliminated string derefs.

I think this gives us the best insight into his thinking:
Replacing percent signs - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=31184

- I think that removing or changing things primarily to 'remove' confusion, never works.
- Until the end of the time, people are still going to do this, even in AHK v2, and start a forum thread on it: if (%var% = 1) when they mean if (var = 1). Perhaps slightly improving the documentation, will reduce the occurrences.
- In my opinion being able to do double deref: var%num%, should persist, and Deref with %% and optionally other characters is the way to go.
- For me I like 'contains', but once in a while, it would be good to use a different character other than comma as the separator, when some of the items contain a comma. The double comma solution has various drawbacks.
- This is why I advocate for the Deref and Verbatim ideas, but with a choice of delimiter character.
- This is why perhaps an 'A_' variable, to temporarily change the separator characters in the Format function could be a good thing, e.g. for use with SendInput.
- This is the simplest solution that I can think of, you have a primary method, and backup options, and you don't have to worry about choosing syntax that is very unlikely to correspond to actual text.
- Keep it simple, stupid. Is often good advice.

[EDIT:]
- Even though I like the command syntax to be doable, one way or another. I supported scrapping its use in commands because having all parameters with one behaviour makes things simpler, and reduces ambiguity. The Deref function would allow you to carry on using it, for the occasional times you wanted it.
- Even if my solutions were implemented, it would still mean that most times I used the Run function, it would be a two-liner (Verbatim, then Run), and not a one-liner. But overall, with all things considered, I would find that to be acceptable. Besides, sometimes it's good to separate text, from the clutter of parentheses, double quotes and commas, i.e. I sometimes use two-liners already.
ltlistener_ftcaller

Re: Reconsideration request?

12 Nov 2017, 07:56

P.P.S. For the old-style command syntax, would it simplify things if we said... leave everything the way it is today with the new syntax, but use assume old unquoted and %deref% syntax just for one line if all of the following are true (and maybe this is sort of like the Verbatim idea of @jeeswg):

    1. There is only one command on the line. It must begin the line (after white space) and no multi-statement can follow.
    2. That command MUST end with a non-optional comma (with no space before the comma): Run, instead of Run
    3. That command is not one of several excluded commands (if and certain flow control commands might come to mind) -- assuming that makes things easier not harder to parse.
I think that would take care of almost every time I would use the old-style syntax. It would almost always be in quickie scripts or isolated run, msgbox or similar statements, where it would be easy to observe a few extra rules... again assuming these restrictions make it easier to differentiate. You could almost ignore the exception in the mainstream documentation (if the worry is confusing people), except to say somewhere generically that you have the option of following the unquoted syntax rules for a single line if you follow all three of the rules.
User avatar
jeeswg
Posts: 2961
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

12 Nov 2017, 08:48

- While I'm not necessarily against any of those proposals. It's a lot of special cases, and little things to remember.
- This is pretty much how I imagined the Verbatim 'command':

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


- Even though I would welcome a Verbatim 'command', I believe also that a Deref function, with essentially the same features would be very useful, for use within standard parameters.
- The difference would be that you would have to add backticks to either double quotes or single quotes where necessary.
- A quirky option, that I'm not necessary recommending, could be something like: dq_, this would mean that wherever you see an underscore, replace it with double quotes. E.g. sq_ for single quotes.
- Some variables that may be useful for AHK v2, what with functions being so common, and readability: A_Comma, A_DQ, A_SQ, A_LParen, A_RParen (or something similar, I'm not necessarily thrilled with (L/R)Paren) for , " ' ( ).
User avatar
jeeswg
Posts: 2961
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

12 Nov 2017, 11:25

- At this link I mentioned the idea of a CdLn (or CmdLn) function.
AHK v2 and strings - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=36833
- It could be replaced by letting the first parameter of the Run function accept an array.

Code: [Select all] [Download] GeSHi © Codebox Plus

vPathExe := "C:\Windows\System32\notepad.exe"
vPath := "C:\MyDir\MyFile.txt"
MsgBox(JEE_CdLn(vPathExe,vPath)) ;"C:\Windows\System32\notepad.exe" "C:\MyDir\MyFile.txt"
Run(JEE_CdLn(vPathExe,vPath))

Run([vPathExe,vPath]) ;perhaps Run could accept an array to achieve the same thing
User avatar
jeeswg
Posts: 2961
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

12 Nov 2017, 12:57

Re. your P.S., that I only just noticed:
if (option1 or Func(option2) or default)
For when option2 can be 0. Cheers.

[EDIT:] You can do a check and optionally set the return value, where ret is passed ByRef.
if Func1(option1, ret) or Func2(option2, ret) or Func3(default, ret)
ltlistener_ftcaller

Re: Reconsideration request?

12 Nov 2017, 20:24

@jeeswg, thanks for all the responses. I did notice one more thing, as I've been fixing old code that used same-line if (from before that was removed). I've used similar ternary workarounds to the ones you cited...

Single-line if workarounds:
(vCond = 1) ? Func1() : Func2()
;these two are equivalent:
(vCond = 1) ? Func1() : 0
(vCond = 1) && Func1()

However, I haven't found a workaround for a same-line "premature" return, like:

Code: [Select all] [Download] GeSHi © Codebox Plus

if this=="", return ""

It's just a mandatory 2-liner, correct? Wondered if someone came up with a bright idea of how to get around it. When I moved to AHKv2 I contracted a bunch instances like these to one liners, and I really liked the result. Same-line in a case like this just as clear to me... if not clearer, because your eyes take the idiom in more quickly. Now I'm exploding them all back out. Such are the woes of using an alpha, I guess. I'm holding out hope that maybe if this=="" {return ""} could be allowed, I guess. Based on what I read on other threads, I don't think Lexikos is likely to add back the if <condition>, <statement> syntax, right?

Speaking of Lexikos, I haven't seen him post much lately? Are you all in contact with him? He's such a big part of things, that if he were not going to be involved as much going forward, that alone might push me over the edge into moving my AHK code base to Kotlin or Python or elsewhere. Not that the guy doesn't deserve a break... he's done such amazing work!!! Transforming a language like this has got to be a thankless job, especially when you've got nuts like me in the peanut gallery penning epistles about their petty gripes over one-line if statements. :)
User avatar
jeeswg
Posts: 2961
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

19 Nov 2017, 22:40

- I didn't notice the last post before, I'm not sure why.
- Having used MS Excel VBA (macros), one of the few things I felt that was missing from AHK was 'if a then b' one-liners, although this was possible with commands. I did mention this in my wish list.
Wish List 2.0 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=13&t=36789
- If it's OK to Exit and not Return, one workaround is:

Code: [Select all] [Download] GeSHi © Codebox Plus

var1 := 1, var2 := 2, Exit()

Exit(vExitCode:=0)
{
Exit, % vExitCode
}

- I think there are about half-a-dozen key things that AutoHotkey needs that can't be done via custom functions, and you've mentioned about half of them, so from my perspective, you've picked the right things.
- I have been thinking of starting an AHK thoughts thread, as the best way to combine wish list ideas, and notes on AHK v1 and AHK v2, and on the AHK source code/C++/reputation/getting more expert coders on board. Keep everything important in one place. And I would start it with a very brief list of the key features that can't be implemented via custom functions.
- Re. lexikos, I asked one or two admins, but they didn't know anything. It would be great to have him back more. If AHK v2 is presenting more and more challenges, we could just finish my 'custom AHK v2 functions for AHK v1' library to get some action now. Pseudo-AHK v2 in AHK v1 would finally give AHK the respect it deserves, and would buy time for AHK v2 proper. Cheers.
User avatar
derz00
Posts: 334
Joined: 02 Feb 2016, 17:54

Re: Reconsideration request?

20 Nov 2017, 09:11

jeeswg wrote:- Re. lexikos, I asked one or two admins, but they didn't know anything. It would be great to have him back more. If AHK v2 is presenting more and more challenges, we could just finish my 'custom AHK v2 functions for AHK v1' library to get some action now. Pseudo-AHK v2 in AHK v1 would finally give AHK the respect it deserves, and would buy time for AHK v2 proper. Cheers.


Lexikos likely has simply lost motivation or is very busy with other things. What AHK needs is greater support by developers. Also, the point of AHK v2 was to introduce changes/improvements that would be incompatible with v1. The intent was never 2-way compatibility. In fact, as it appears to me, the intent was the exact opposite, for the sake of improving some functionality, and providing expression (function) syntax for built-in commands. It's kind of the same way with Python 2 and 3--they are not compatible.

It would be a good idea to pick out and organize the many disorganized threads in Bug Reports, Wish List, AutoHotkey v2 Development forums which contain many good ideas/suggestions, with the intent of providing developers a springboard/to-do list.
try it and see
User avatar
jeeswg
Posts: 2961
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

20 Nov 2017, 11:09

What AHK needs is greater support by developers.

- Chicken or the egg. AHK will attract more developers when it's improved, hence AHK v2.
- What developers, how many AHK users or non-users have that level of C++ and understanding of AutoHotkey?
- From my perspective, I can do things to encourage the growth of AutoHotkey. By finishing my tutorials, including conversion tutorials/scripts. To encourage the understanding of the source code: I've been recreating functionality via DllCall to explain various functions/built-in variables etc. I'm learning C++ pretty slowly. I have read much of, and intend to read the source code, in full, and make summary notes on it. I have asked for a C++/AutoHotkey forum section. I produced an extensive wish list, and have created workaround functions for everything that didn't involve additions to the source code. I intend to publish more of my core functions and scripts over time.

Also, the point of AHK v2 was to introduce changes/improvements that would be incompatible with v1. The intent was never 2-way compatibility.

- I see AHK v2 in two ways.
- (1) Introduce various things that are two-way compatible e.g. function versions of commands. And remove certain aspects of the syntax that are currently deprecated. You get pseudo-AHK v2 in AHK v1 if you do this, with 95%-99% of the functionality of AHK v2.
- (2) Introduce certain things that are incompatible with AHK v1.1.
- Of course developers can work on the C++ first, but I would suggest working on an 'AHK v2 functions for AHK v1' library first, and getting that fixed, that's the core of moving AHK towards AHK v2.

It would be a good idea to pick out and organize the many disorganized threads in Bug Reports, Wish List, AutoHotkey v2 Development forums which contain many good ideas/suggestions, with the intent of providing developers a springboard/to-do list.

- Well someone has to do that. I'm working on my version, other people can work on theirs.
User avatar
derz00
Posts: 334
Joined: 02 Feb 2016, 17:54

Re: Reconsideration request?

20 Nov 2017, 12:22

jeeswg wrote:- Of course developers can work on the C++ first, but I would suggest working on an 'AHK v2 functions for AHK v1' library first, and getting that fixed, that's the core of moving AHK towards AHK v2.


You state this confidently, but maybe a poll would reveal how core that is. I can see the convenience, but in a way, one must simply choose AHK v1 or v2 and just program in the version you choose.
try it and see
User avatar
jeeswg
Posts: 2961
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

20 Nov 2017, 12:47

but maybe a poll would reveal how core that is.
- How core what is? I think it's an accurate statement to say that the core of conversion to AHK v2, is to replace your commands with functions (or to functions with command-like syntax if they are kept).

I can see the convenience
- By this approach, the convenience is primarily for the developers, although it would be convenient for users also. It's easier to tinker with and perfect custom AHK v1 functions first in AHK, and then create the AHK v2 functions in C++.
- lexikos had suggested it would be a good approach to consider ways to ease the transition from AHK v1 to AHK v2, and the 'AHK v2 functions for AHK v1' library would be key to that.
- The main devs could say that particular 'AHK v2 functions for AHK v1' were considered finished, so that you could begin converting a subset of commands in your AHK v1 scripts to AHK v2-like functions. That way people can gradually convert their AHK v1 scripts to make them more and more AHK v2 ready, until AHK v2 is officially released. That way we make gradual concrete progress towards AHK v2.

but in a way, one must simply choose AHK v1 or v2 and just program in the version you choose.
- Not really. I chose to use 'AHK v2 functions for AHK v1', to make my scripts pseudo-AHK v2 scripts, I have the best of both worlds, the stable AHK v1, and the AHK v2 functions, I've removed the use of commands, and my scripts are virtually ready to be used in AHK v2 when it's completed.
User avatar
nnnik
Posts: 2309
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Reconsideration request?

20 Nov 2017, 13:31

The issue with AHK v2 is that currently nobody is actively developing it besides lexikos. lexikos has been absent since quite a while and I can't see signs of active progress.
What AutoHotkey lacks right now is developers not someone that will smooth the transition from AHK v1 to AHK v2. We don't need to attract developers that might help with the project in the far future.
We need someone that develops and we need this person now. AHK had many outstanding developers.
Many developers that were capable of both C++ and AHK - however many of them left. It is difficult for me to tell in which direction lexikos wants to take AHK.
I'd also like to determ the direction even if it's only a little bit. I'd like to support this community by working on the AutoHotkey source.
However I don't know lexikos plans for the language and I don't know a lot of the source code.
I feel that both is something that keeps everyone from helping with the source - removing these hurdles would be a good idea.
I really like jeeswgs plan to read the entire source code and make a tutorial on how to understand it - maybe we can also make a new section named "source code discussion".
However that won't lead to knowing lexikos plans.

I think that with the AutoHotkey LLC we have taken a step in the right direction - we should probably go further down that direction and extend it's influence over to the AutoHotkey language.
I think we should form some sort of consortium ( or another institution ) that defines and develops the language, the services provided and communicates the results with the users.
That way we can attract people that actively want to take a role in AutoHotkeys development process.
However I am not the one allowed to make a decision in this case - this is up to lexikos to decide.
Recommends AHK Studio
just me
Posts: 4862
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Reconsideration request?

20 Nov 2017, 16:41

jeeswg wrote:Not really. I chose to use 'AHK v2 functions for AHK v1', to make my scripts pseudo-AHK v2 scripts, I have the best of both worlds, the stable AHK v1, and the AHK v2 functions, ...
How would built-in commands wrapped in user functions be "the best of AHK 1.1"? They just cost unnecessary overhead.
Remaining with AHK 1.1.25.02 until v2 will become beta.
User avatar
jeeswg
Posts: 2961
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

10 Dec 2017, 11:16

- @nnnik: I don't particularly feel that AutoHotkey *needs* (in the strictest sense of the word) updating right now, apart from an 'assume local' mode, a few considerations re. #Include, and perhaps some changes with regard to Windows 10 (which don't affect me right now, as I don't use Windows 10). Beyond that, I would like to see various tweaks to existing functions, that I've documented in Wish List 2.0.
- Generally I think it's important to get new people into AutoHotkey, and currently, more important than improving AutoHotkey, is getting AutoHotkey's reputation where it deserves to be, by deprecating commands and moving to functions, right now, in both AHK v1 and AHK v2. This could have easily been done 5 years ago or more. [EDIT: 12 years ago.]
Commands as functions - Scripts and Functions - AutoHotkey Community
https://autohotkey.com/board/topic/3531-commands-as-functions/
- Perhaps our greatest need is to get more people who understand COM, i.e. latching onto and interacting with interfaces. I don't mean automating IE/Excel, which is easier. But generally, the more the people the better. I can count on one hand, a few recent newcomers, from 2016-2017, who have made a massive difference to my AutoHotkey experience.
- This is the default view of AutoHotkey, as recently as September 2016, from programmers unfamiliar/semi-familiar with it, even those who are experts in automation. What's worse is, I agree with that view. And all it's going to take to fix it, is the move to functions. Even simply using my functions library will fix it.
Al Sweigart, "Automating Your Browser and Desktop Apps", PyBay2016 - YouTube
https://www.youtube.com/watch?v=dZLyfbSQPXI#t=1960

- @just me: I said 'the best of both worlds', stability is good, functions instead of commands is good. Clearly increased overhead is bad, however, if AHK v2 isn't fully optimised yet, perhaps there is overhead there also? (When AHK v2 is officially released, I'll be happy to encourage/help people to move over.)
- Also, just how much overhead is there, I'd like to know. You're welcome to furnish this thread with the results of some benchmark tests. Plus, there are advantages in writing code when you have functions available, to make certain things more fluid.
- Btw 'Remaining with AHK 1.1.25.02 until v2 will become beta.' What's wrong with AHK 1.1.26.01?
User avatar
derz00
Posts: 334
Joined: 02 Feb 2016, 17:54

Re: Reconsideration request?

Yesterday, 09:31

jeeswg wrote:- @nnnik: I don't particularly feel that AutoHotkey *needs* (in the strictest sense of the word) updating right now, apart from an 'assume local' mode, a few considerations re. #Include, and perhaps some changes with regard to Windows 10 (which don't affect me right now, as I don't use Windows 10). Beyond that, I would like to see various tweaks to existing functions, that I've documented in Wish List 2.0.


What @nnnik means is what he said: "development". Every language needs (in any sense of the word) development to stay "reputable". What you describe above is an element of development.
try it and see

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 1 guest