You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Improve debugging experience for method chains.For example, For example, only method d breaks in a method chain like a.b().c().d()
Inline breakpoint is a feature that is not available in the AutoHotkey debugger. Therefore, they need to be controlled by debug adapter to behave like inline breakpoint.
Although not directly related to inline breakpoint, method chains containing line breaks such as the following must also be targeted.
1| a
2| .b()
3| .c()
4| .d()
5| return
If you set a breakpoint on line c() in the example above, the debugger will re-set the breakpoint on line 5.
Also, the AutoHotkey debugger executes the c method immediately after the b method is executed.
In contrast, the node debugger returns to the first line of the caller after b() is executed. Then c() is executed and it returns to line 1 in the same way.
These differences can be seen when you do a step-out execution: in AutoHotkey, if you step out in the b method, it ignores the subsequent method chain and moves the cursor to line 5, which is the next statement.
In node debugger, step-out in the b method returns to the caller, so step-in execution can debug the c method.
This issue also deals with these.
Solution
Inline breakpoint in this situation behave like conditional breakpoint.
This breakpoint must be verified and its position corrected on behalf of the debugger.
This verification uses AELL (AutoHotkey Expression Like Language), which is enabled in v2.0.0.
As AELL supports AutoHotkey expressions, the following code can be analysed.
1|globalAdd := (a, b) => a + b
2| ; ^ Correct breakpoint position here
The kind of expression must be determined by verification, and the correction one or behaviour must be changed depending on the kind of expression.
For example, if it is a Fat Arrow Function as shown above, the breakpoint is corrected to the position in the comment and the condition A_FuncName == "()" is set to the target breakpoint. Conversely, if the target breakpoint is not an inline breakpoint, the condition A_FuncName ! = "()". This condition controls whether the break occurs at the time of assignment or at the time of call.
Next, consider the following method chain.
a.b().c().d()
For this problem, considering the behaviour of the AutoHotkey debugger as explained above, consider the following.
Verify the calling expression near the position to the inline breakpoint. Also, count the number of times the call expression is up to that position. After the step-in is executed, repeat the following steps for the number of call counts.
customised step execution to the end of the method
step over. In other words, move to the next method
The above steps can be used to break at a pseudo-target method.
The text was updated successfully, but these errors were encountered:
RELATED: #265, #315, #319
I don't know if v2.0.0 will solve this issue, but it is an issue I would like to finally solve.
Why implement?
Inline breakpoints primarily solve the following problems.
a.b().c().d()
Inline breakpoint is a feature that is not available in the AutoHotkey debugger. Therefore, they need to be controlled by debug adapter to behave like inline breakpoint.
Although not directly related to inline breakpoint, method chains containing line breaks such as the following must also be targeted.
If you set a breakpoint on line c() in the example above, the debugger will re-set the breakpoint on line 5.
Also, the AutoHotkey debugger executes the
c
method immediately after theb
method is executed.In contrast, the node debugger returns to the first line of the caller after b() is executed. Then c() is executed and it returns to line 1 in the same way.
These differences can be seen when you do a step-out execution: in AutoHotkey, if you step out in the b method, it ignores the subsequent method chain and moves the cursor to line 5, which is the next statement.
In node debugger, step-out in the b method returns to the caller, so step-in execution can debug the c method.
This issue also deals with these.
Solution
Inline breakpoint in this situation behave like conditional breakpoint.
This breakpoint must be verified and its position corrected on behalf of the debugger.
This verification uses AELL (AutoHotkey Expression Like Language), which is enabled in v2.0.0.
As AELL supports AutoHotkey expressions, the following code can be analysed.
The kind of expression must be determined by verification, and the correction one or behaviour must be changed depending on the kind of expression.
For example, if it is a Fat Arrow Function as shown above, the breakpoint is corrected to the position in the comment and the condition
A_FuncName == "()"
is set to the target breakpoint. Conversely, if the target breakpoint is not an inline breakpoint, the conditionA_FuncName ! = "()"
. This condition controls whether the break occurs at the time of assignment or at the time of call.Next, consider the following method chain.
For this problem, considering the behaviour of the AutoHotkey debugger as explained above, consider the following.
Verify the calling expression near the position to the inline breakpoint. Also, count the number of times the call expression is up to that position. After the step-in is executed, repeat the following steps for the number of call counts.
The above steps can be used to break at a pseudo-target method.
The text was updated successfully, but these errors were encountered: