Assorted & Unsorted AutoHotkey v2 Wish List

[fincs]

Here's my personal collection of suggestions for v2 (I may try to implement any of these myself):

• OnExit: make it accept a function instead of a label. The function would optionally accept an exitReason parameter removing the need for A_ExitReason.
  Return value of an OnExit handler: blank/false = normal exit, true = block script exit.
• OnMessage: accept function references & generalize to allow filtering by window:

  Code: Select all

  OnMessage(HWND, MsgNumber [, Function, MaxThreads]) ; if hwnd = 0 then no filtering is applied

• OnClipboardChange: make into a set-handler function like OnExit. Said handler function would accept one parameter (reducing the number of usages of A_EventInfo by one).
• ClipboardAll (& related FileRead/FileAppend behaviour): replace with a more intuitive mechanism that doesn't use a quirky binary variable mode.
• Rename #IncludeAgain to #ForceInclude

Deeper changes that do not necessarily have to be implemented in v2 and may need more thought:

• GUI: major redesign to factor in objects & replace usage of labels with functions.
• Menu: major redesign similar to that of GUI.
• Hotkeys and hotstrings: make them functions, e.g.

  Code: Select all

  #v::
  {
      MsgBox Command #1
      MsgBox Command #2
  }
  
  #!v::MsgBox Note that oneliners still have the same old and simple syntax

  Disadvantage: no longer possible to fall-through and use Gosub to call the code of a hotkey/hotstring. The latter usage is considerably rare, but the former is not.
• Remove Gosub: since all functionality that formerly used subroutines has been reworked to use functions, Gosub can now be safely removed. This also includes removing all the built-in variables used for event subroutines.
• @FuncName syntax for inserting function references that are resolved at load-time. @Dynamic%References% also supported.

[lexikos]

OnMessage already accepts function references, thanks to this commit. However, it still requires a native Func.

Rename #IncludeAgain to #ForceInclude

Why?

since all functionality that formerly used subroutines has been reworked to use functions,

Except for subroutines in functions...

@FuncName syntax for inserting function references that are resolved at load-time.

If you're thinking about performance, Func("FuncName") could easily be optimized to be resolved at load-time.

Disadvantage: no longer possible to fall-through

I see no reason this couldn't be possible:

Code: Select all

#v::
#!v::
{
   ; both hotkeys refer to this function
}

...but agree this wouldn't be:

Code: Select all

#v::
  a := 1  ; whether in braces or not
#!v::
{
   ;...
}

The latter form is much rarer, I think.

[fincs]

OnMessage already accepts function references, thanks to this commit.

Missed that, whoops.

Why?

Because it doesn't include the file 'again', its real meaning is "inconditionally include it here". Consider this:

Code: Select all

#IncludeAgain someFile.ahk ; 'again'? Where was it included before?
; more code

If you're thinking about performance, Func("FuncName") could easily be optimized to be resolved at load-time.

Yeah, that would also suffice. It may be even a good idea to implement this optimization in v1.1, too.

I see no reason this couldn't be possible:

I missed that :p

[just me]

Code: Select all

#v::
{
    MsgBox Command #1
    MsgBox Command #2
}

This shall be a function?

[lexikos]

Because it doesn't include the file 'again', its real meaning is "inconditionally include it here".

And? What will #ForceInclude mean to the majority of users? I think #IncludeAgain is more likely to get the meaning across, even if it doesn't satisfy pedants.

One would use #IncludeAgain when including something multiple times. If one wants to strictly take its name at face value, then one would use the #Include directive first, then #IncludeAgain, which will work. To do anything else would show that you really know what it means anyway, and the name is fine.

Nothing has changed since the directive was introduced. I stand by Chris' naming decision.

[haichen]

Never thought about this before, but ... My question is: does i need #include? If I understand it right (may be not)
I can do everything with #includeagain what i can do with #include.

Where does i want to write code with multiple instances of "#include thisfile" and want only one to be included?
Can't we replace #include with #includeagain? .. and finally rename it to #include?

May be silly questions.

[fincs]

Where does i want to write code with multiple instances of "#include thisfile" and want only one to be included?
Can't we replace #include with #includeagain? .. and finally rename it to #include?

See Include guards in C/C++.

[strobo]

include is transitive, so
if a includes b and a includes c and b includes d and c includes d, then,
a includes d two times, technically at different places. To avoid sth like "duplicate function definition" #include keeps track of the files to avoid double #includes.
From this perspective #ForceInclude makes more sense than #IncludeAgain, as, i.g. b does not know that c has already included d. Hence, b has a limited notion of including-again, but a notion of forcing an inclusion. In short, including-again is a notion which is out of b's scope.

If one wants to strictly take its name at face value, then one would use the #Include directive first, then #IncludeAgain, which will work.

not for b, it only knows about the first occurence in its scope, so #include may or may not include (depending on outer scopes).

[lexikos]

So you wouldn't use #IncludeAgain in that case, unless you already knew that it would work even if #Include hadn't been used. This is my point. Well, I suppose you could just do it on the possibility it would work, if you're not unreasonably strict with your interpretation of command names.

Even if we rename the directive, one has to consider the possibility that the file was already included before choosing #ForceInclude/#IncludeAgain over #Include. One also has to know that #Include only happens once, unlike in C and C++.

It would be more logical to rename the directives #IncludeOnce and #Include; however, I see very little benefit in such a change. Once again,

Nothing has changed since the directive was introduced. I stand by Chris' naming decision.

[Hawkysoft]

A way that decompilation is more secured if possible?

[Coco]

Perhaps add a scope parameter to IsLabel() that accepts the word global(by default) or local.
Usage example:

Code: Select all

fn(name) {
    goto % IsLabel(name, 'local') ? name : 'nada'
    foo:
    bar:
    return true
    nada:
    return false
}

[RHCP]

What about the ability to resume interrupted threads when the interrupting thread sleeps or calls a special command?

As it currently stands:
Thread B interrupts thread A
Thread B then loops/sleeps while waiting for something to happen
Result: Thread A will be halted until thread B finishes.

There are ways to minimise this issue, but It would be cleaner if you could just allow interrupted threads to be resumed.
I guess this would probably require a lot of work, but it never hurts to ask

[lexikos]

RHCP, it's not feasible. Or relevant.

[vasili111]

Remove Gosub: since all functionality that formerly used subroutines has been reworked to use functions, Gosub can now be safely removed. This also includes removing all the built-in variables used for event subroutines.

Please DONT remove Gosub. It is very convinient to use Gosub with free type diagrams in DRAKON-AutoHotkey ( http://ahkscript.org/boards/viewtopic.php?f=6&t=3108 ).
There is not proposed but also please don't remove Goto. It is needed for Free type diagrams in some cases.

[fincs]

Why can't you use functions with assume-global mode instead of subroutines? Also, nobody said anything about removing Goto (and in fact I also oppose its removal).

[toralf]

Remove Gosub: since all functionality that formerly used subroutines has been reworked to use functions, Gosub can now be safely removed. This also includes removing all the built-in variables used for event subroutines.

If GoSub gets removed then you could as well remove the subroutines as well.
IMHO this is getting too far, without GoSub the user is 'forced' to use functions. Maybe I'm just used to it from the past, but I was very happy as a beginner to use GoSub. I think it is on of the simple concepts that makes AHK so attractive for beginners.

[joedf]

+1

[toralf]

+1

for what?

[joedf]

I agree with this:

If GoSub gets removed then you could as well remove the subroutines as well.
IMHO this is getting too far, without GoSub the user is 'forced' to use functions. Maybe I'm just used to it from the past, but I was very happy as a beginner to use GoSub. I think it is on of the simple concepts that makes AHK so attractive for beginners.

[kon]

I agree with that also. It is tempting to remove gosub because so many new users get into trouble by not ever using a return so their scripts crash. Gosub is still appealing and easy to understand for new users, so for that reason I favor keeping it. But instead of eliminating the command, I think it is better to advise new users to use goto instead.