Renamed variables/functions

[Lexikos]

Some variables and commands/functions exist in both versions, but have been renamed. You may find lists in v2-changes under "Renamed:". (In some cases the usage has also changed.)

For example, A_LoopFileFullPath was renamed to A_LoopFilePath and A_LoopFileLongPath was renamed to A_LoopFileFullPath. If left as is, A_LoopFileFullPath is now actually the full path (whereas before it could be relative) and is case-corrected, while A_LoopFileLongPath is undefined.

Or is this outside the scope of this script? How complete is the conversion intended to be? As much as feasible?

[FuPeiJiang]

:OOOOOOOOOOOOOOOOOOOOO LEXICOS
-me this morning
-I really didn't know what to reply, was too shocked, And also tired
need to calm down, emotional can't code
took a break, rested, and now,

thank you for giving me hope (I needed it again) for this project
, how did you find it ?
thanks for the help and links, I knew the parser must've been inside AHK.exe itself, but I feared looking into c++.
the documentation is too good, the best I've seen

I'll write(replies) about the code tomorrow

[FuPeiJiang]

so before, I was doing clipboard -> A_Clipboard using a function like this, I could easily add more.
this replaces: HERE:="" & v:=HERE & v=a%HERE%b
I mean, var being assigned, var in v2Expression, %var% in v1Expression
I don't know if a_loopfilelongpath can be assigned to, but that's not up to the converter to fix?

7eca656#diff-5ba5444a568db9aa720762591b0381021e9e66d0d39fa92089e7841cad4401b2R88

  //https://www.autohotkey.com/v2/v2-changes.htm#built-in-variables
  renameVar('a_loopfilefullpath','A_LoopFilePath')
  renameVar('a_loopfilelongpath','A_LoopFileFullPath')
  renameVar('clipboard','A_Clipboard')
  renameVar('comspec','A_ComSpec')

---

functions.
I'm just gonna save this link for functions : https://www.autohotkey.com/v2/v2-changes.htm#built-in-variables#:~:text=ComObjCreate()%20-%3E%20ComObject(),%20which%20is%20a%20class%20now

currently I'm doing functions manually because I expected them to be much different
this is code for : varsetcapacity() -> BufferAlloc() or .Size

      if (thisLowered === 'varsetcapacity') {
        //#function
        if (getArgs()) { return 2 }
        if (argsArr.length === 1) {
          // VarSetCapacity(TargetVar)
          // TargetVar.Size
          a(1); p('.Size'); s()
        } else {
          // VarSetStrCapacity(TargetVar, RequestedCapacity, FillByte)
          // TargetVar:=BufferAlloc(RequestedCapacity,FillByte)
          a(1); p(':=BufferAlloc('); a(2); o(',',3); a(3); p(')'); s()
        }
      }

I kinda need a priority for functions to convert, which ones do I do first ?

[Lexikos]

I kinda need a priority for functions to convert, which ones do I do first ?

Find scripts which need conversion that isn't done yet, fix the conversion, test, repeat. I think I would find that approach more motivational than prioritizing a list and working through it. It's good to regularly see your work paying off.

[FuPeiJiang]

the reason I started using v2 was a coincidence, I "needed?" multithreading for ahk_explorer FuPeiJiang/ahk_explorer#6, I wanted to try AHK_H, decided to also try v2 at the same time, so AHK_H v2,
but then I gave up: If I was going to convert ahk_explorer to v2, I'd rather rewrite it, because it was poorly written.
that was too much repetitive work, and ahk_explorer worked fine. so I didn't want to rewrite it anymore

---

I started using WinClip.ahk, and decided to use v2, so I had to convert it using v2, at the start, I used many RegExReplace(), worked, but didn't work perfectly.
I also wanted to convert object to map: {a:12}->Map("a",12)

I successfully did that, and now I have nothing that I want to convert. I ran out of reasons to convert v1 to v2
I will continue writing new scripts in v2 though

---

v1 vs v2
for small scripts, v1 is better, less typing to be done:

1. no need for brackets for hotkeys: brackets takes 1 more line than return

f3::
{
}

vs

f3::
return

somehow, the one with return looks nicer to me: maybe I'm just used to seeing it

2. no need to declare global variables (I COULD turn #warn off though)

f3::
{
global foo, bar
}

global could be helpful for large scripts
I think v2 is more organized (all the GUI functions) (haven't tried though)

---

but I'm also using typescript for no reason(for a challenge I guess, AND because people are using it, and I like to use the newest). It helped me only Some times, on minor things.
I'm now getting tired of typescript, and of everything

typescript: I learned project management, I gave myself another puzzle

---

my v1 scripts work, and they look nicer. why convert ?
but it was the same when I started this project, and I still did it, why ?
I remember it was really exciting to successfully parse AHK, I was defeated every 10 minutes
I really liked taking down huge challenges, but now, I feel I don't have the energy for it
and I wanted to feel like I was doing something

[FuPeiJiang]

v2 function call without () is cool
I can easily MsgBox like this
p "hello world"
oh, but the quotes, but that never happens, I always msgbox variables: p var

[Lexikos]

This might not be the best place for such a discussion...

for small scripts, v1 is better, less typing to be done

I disagree. Using braces with hotkeys means that you do not need return, which means less typing. The open brace can be placed on the same line as the hotkey, so it does not even require more lines. There are also several other advantages.

For small scripts, the cost of "more typing" is proportionately small. Small scripts can still be affected by common points of confusion in v1. Authors are still required to take into account the syntax inconsistencies, whatever size the script is.

no need to declare global variables

In v1? Unlike v1, there is no need to declare global variables inside functions in v2 if they are only being read. If the hotkey modifies a global variable it must be declared, which requires more typing as you say, but carries the benefits of showing clearly which global variables a hotkey might modify and reducing unintentional sharing of variables.

why convert ?

I might convert my main hotkey scripts so that when I add new hotkeys, I'm not forced to use v1 syntax, and I'm able to take advantage of features unique to v2. It's not worth converting manually because it would be much more work than simply continuing to use v1 syntax, given that I don't change these scripts often.

Others might argue that having decent automatic conversion (even if it can't be 100%) might reduce the resistance for some users to upgrade. I intend to create tools for this myself, as v2 scripts.

[FuPeiJiang]

This might not be the best place for such a discussion...

why not ? because it's outside the scope of this github issue? is there a better place ?

---

The open brace can be placed on the same line as the hotkey

wow I didn't know that, it's way quicker
this looks nice now

$f1::{
  send "^c"
  sleep 100
  A_Clipboard:=StrLower(A_Clipboard)
  send "^v"
}

I should edit my converter

---

there is no need to declare global variables inside functions in v2 if they are only being read.

it may be because I'm using AHK_H v2, which hasn't been up to date

var:=1
$f1::{
  msgbox var
}

Warning: This variable appears to never be assigned a value.

Specifically: local var (same name as a global)

but carries the benefits of showing clearly which global variables a hotkey might modify and reducing unintentional sharing of variables.

this made me remember this
https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html#mutable-references

• Two or more pointers access the same data at the same time.
• At least one of the pointers is being used to write to the data.
• There’s no mechanism being used to synchronize access to the data.

---

I intend to create tools for this myself, as v2 scripts.

string manipulation in ahk is harder, that's why I chose javascript, and it can be on website
but now I realize that the most important is the debugger, there is v1 ahk debugger in vscode, but no v2 debugger

[Lexikos]

is there a better place ?

That depends on whether you would welcome alternative opinions. Here, your comments have low visibility; i.e. they (and my responses) will likely be seen only by someone who is interested in this Issue. If you are interested in sharing or testing your opinion and maybe learning something new, you are likely to get more input by posting on the autohotkey.com forums.

it may be because I'm using AHK_H v2, which hasn't been up to date

Right. It is a reasonably recent change.

there is v1 ahk debugger in vscode, but no v2 debugger

vscode-autohotkey-debug by zero-plusplus supports both versions. There is very little reason that any debugger client would support only one version, since they both use the same protocol.

[FuPeiJiang]

on the autohotkey.com forums.

should it be in AutoHotkey v2 Development ?
is there already a thread for this ?
I'm already convinced to use v2 though

If you are interested in sharing or testing your opinion and maybe learning something new, you are likely to get more input by posting on the autohotkey.com forums.

I'll keep that in mind
(over/instead of) thinking about everything that could go badly if I post(new topic) or comment(reply)

---

vscode-autohotkey-debug by zero-plusplus:

Debugging support for AutoHotkey(includes H) v1 and v2

sorry, didn't look if there were any debugger for v2, I'm using AutoHotkey Plus Plus by Mark Wiemer
and I assumed that it was the only extension that existed, or the extension that had everything.
there was no support for v2 there so I said "there was no debugger for v2 in vscode"..

There is very little reason that any debugger client would support only one version, since they both use the same protocol.

well, it's running my v2 .ah2 using v1 AutoHotkey.exe so I'm getting syntax errors, the debugger client may work if v2 AutoHotkey.exe was ran

thanks for this extension
I'll just link it for when I'm going to need it vscode-autohotkey-debug by zero-plusplus

This extension will not work alone. A separate extension that supports the AutoHotkey language is required(The most famous is slevesque.vscode-autohotkey). If you are using AutoHotkey v2, another extension that supports it required. (e.g. dudelmoser.vscode-autohotkey2)

why does it need separate extensions ?

---

zero-plusplus/vscode-autohotkey-debug#90
ooooooooooo, this person is also trying to write a parser

I've been trying to detect symbols (classes, functions, etc.) for the past few days. As a result I realized that it is difficult to solve this without using a parser.

So I decided to create a parser from scratch.

then they say they'll be using Tree-sitter, I'll see what this is

[Lexikos]

well, it's running my v2 .ah2 using v1 AutoHotkey.exe

Just set the runtime in the launch.json file of the current workspace. Different projects can use a different exe.

In my case, the default path is C:\Program Files\AutoHotkey\v2\AutoHotkey.exe, which doesn't exist. This is documented (by the extension author) as the default for when the extension is .ahk2 or .ah2, but I only use .ahk, so I don't know why it does that. I use VSCode only for v2, with thqby/vscode-autohotkey2-lsp, which has its own setting for AutoHotkey.exe path.

There's no official installer yet for v2, and therefore no official path.

why does it need separate extensions ?

I don't know why the debug extension needs a language extension, but if you don't have a language extension, you won't have syntax highlighting or other language support that is unrelated to the debugger.