@Debug-Breakpoint => vs @Debug-Output

[Lexikos]

I guess it's intended that ; @Debug-Breakpoint => message doesn't break, like logpoint, but isn't that the same as ; @Debug-Output => message?

I find myself using both directives together, to both break and display information that shows why I'm at a breakpoint and save me the trouble of inspecting variables.

I think it would be more useful for Breakpoint to break even if there is a message, and not automatically resume after logging the message.

[zero-plusplus]

I guess it's intended that ; @Debug-Breakpoint => message doesn't break, like logpoint, but isn't that the same as ; @Debug-Output => message?

Yes, they are. It was intended and implemented.

@Debug-Breakpoint is a feature that sets breakpoints, hit breakpoints, and logpoints.

And @Debug-Output was implemented as a restricted version of @Debug-Breakpoint that only sets logpoints.

This was intended as an alias to clarify that it outputs a message. Therefore, the feature is duplicated.

Later, when I added message grouping to @Debug-Output, I thought about changing the behavior to break and output message to differentiate it from @Debug-Breakpoint, but decided against it for the following reasons.

• @Debug-Breakpoint is a feature to set breakpoints without UI, so it is necessary to match the feature with the case where breakpoints are set by UI.
• If a variable is to be checked when a script is broken, there are alternative features such as WATCH expressions
• The same effect can be obtained by setting a breakpoint on the line of @Debug-Output from the UI, or by adjoining @Debug-Breakpoint to the line

I find myself using both directives together, to both break and display information that shows why I'm at a breakpoint and save me the trouble of inspecting variables.

I hadn't thought of a way to output the reason for the break. Surely that way it would be better to have both the break and the message output executed.

It would be possible to solve this issue if a short hand with the following equivalent feature could be provided.

; @Debug-Breakpoint
; @Debug-Output => message

My idea is to extend the output operator as follows.

; @Debug-Breakpoint &=> break reason
; @Debug-Output &=> break reason

The & was added at random. If you have any other ideas, please let me know.

[Lexikos]

I will accept whatever behaviour you choose, but I do not agree with your explanations.

@Debug-Breakpoint is a feature to set breakpoints without UI, so it is necessary to match the feature with the case where breakpoints are set by UI.

I don't follow your reasoning. Why is it necessary for @Debug-Breakpoint to cover everything that you can do with a "breakpoint" in the UI, when some of that functionality is better achieved with a different directive?

If a variable is to be checked when a script is broken, there are alternative features such as WATCH expressions

That is not a suitable alternative.

• As far as I know, it requires adding a watch using the UI. I do not know where this is recorded, but wherever it is, I won't be checking it into git. If I (or someone) clones the repository, these watches won't exist.
• I want to be informed about this condition at some distant time in the future, when I have long forgotten about the possibility and would not have a watch set in the UI.
• There could be many different places in the code where a break condition could be met, and each one could have a different message with variables. Having a watch for each one would not be practical, because the list would not be limited to only the one relevant for the current breakpoint.

The same effect can be obtained by setting a breakpoint on the line of @Debug-Output from the UI

If I'm going to use the UI, why use a directive at all? Again, it's not a suitable alternative.

or by adjoining @Debug-Breakpoint to the line

Right, ;@Debug-Breakpoint => Message doesn't break, so we must use

;@Debug-Breakpoint => Message
;@Debug-Breakpoint

I think that highlights why the current behaviour doesn't make sense.

It is redundant for @Debug-Breakpoint => to perform the same function as @Debug-Output =>. Having Breakpoint break is both more intuitive and more convenient (because I can use one directive instead of two).

I don't see any advantage to the current behaviour.

The & was added at random

You could use . to mean "full stop" (break). But it would be more intuitive for break to mean break.

[zero-plusplus]

I don't follow your reasoning. Why is it necessary for to cover everything that you can do with a "breakpoint" in the UI, when some of that functionality is better achieved with a different directive?@Debug-Breakpoint

vscode allows a single breakpoint to have a condition, a hit condition, and a log point at the same time.

When these are set simultaneously, a logpoint is output only when both the condition and the hit condition are matched. In this case, no break is made.

To reproduce this specification, breakpoint directives do not output logs and break at the same time.

If a variable is to be checked when a script is broken, there are alternative features such as WATCH expressions

That is not a suitable alternative.

This was my thinking at the time of implementation and I do not think so now.
I think it is necessary to provide a way to run output and break at the same time.

You could use . to mean "full stop" (break). But it would be more intuitive for break to mean break.

"full stop" (break) means stop debugging?

---

I thought about this while writing the above, and you are right, it would be more beneficial to the user if breakpoint directives always break the script, regardless of the output.

The use of three simultaneous breakpoint settings in the UI is something many people are unaware of, and I didn't think I should insist on recreating it.

Thanks for your opinion, I appreciate it.

---

The release of the next version will be delayed due to a lack of time.

If you want to use the latest version immediately, clone the develop branch and run the following commands in a terminal to create vsix.

• npm install
• npm run package

[Lexikos]

I realized I haven't been using the reply function of this discussion...

In this case, no break is made.

Are you saying that the directive sets a single breakpoint, and a single breakpoint cannot both break and display a message?

To reproduce this specification, breakpoint directives do not output logs and break at the same time.

When you say "reproduce this specification", this strongly implies that the directive isn't limited by the general behaviour of breakpoints, but rather that you have specifically made it copy that behaviour - reproduced it. So my question is still why do that? But maybe that's not what you meant.

Even so, two directives in a row can achieve the desired effect, even with both targeting the same line. It must be possible for one directive to achieve the same effect.

"full stop" (break) means stop debugging?

No, break means break. It stops running (temporarily).

clone the develop branch and run the following commands in a terminal to create vsix.

Thanks for the tip.

[zero-plusplus]

Applied change #238 in the develop branch.

If you find a bug, please report it in the Issue above.