Logpoint UX Issues: Toggle vs Add

[hediet]

• VSCode Version: 1.45
• OS Version: Windows 10

Steps to Reproduce:

1. Invoke the command editor.debug.action.toggleLogPoint.
2. Invoke it again.

Actual Result

There is still a logpoint.

Expected Result

The second invocation should toggle the log point so that there is no logpoint anymore.
Also, the translation should be "Toggle Logpoint" and not "Add a Logpoint".

Also, the logpoint is inserted at the column where the cursor was when the command is invoked. This is strange.

If this is all design, the command should be renamed or another command should be added.

Does this issue occur when all extensions are disabled?: Yes

[isidorn]

@hediet thanks for letting us know.
Yeah we were using a wrong id. This is actually an action to add a logpoint, not to toggle it.
Thus I have changed the id.

[hediet]

Did you see the behavior in the gif of how the logpoints are inserted just where the cursor is? That is really annoying.

[hediet]

I still think the UX is not great with the new Add Logpoint command.
If the current line already has a logpoint, this command is useless.

It would be cool if a subsequent call to this command would

• either actually toggle the logpoint, i.e. remove the logpoint
• or offer the ability to edit the current logpoint rather than showing an empty expression field that would overwrite the existing logpoint.

I think Logpoints are way underused. I think they are a perfect alternative to the console.log debugging a lot of people use. If I had got the idea earlier that I can bind the "Add Logpoint" command to a shortcut by myself, I would have used them way more.

[isidorn]

Thanks for feedback, we can reopen this issue and look into the logpoint improvments some time in the future.

[hediet]

I would love if logpoints could be made easier to use and more fun to work with.

I see the following problems in the current implementation:

1. It is hard to see the expression of an existing logpoint. You have to use the mouse for that.
2. It is hard to change the expression of an existing logpoint. You have to use the mouse for that.
3. Add Logpoint is not bound to a keybinding. This can be easily configured, but I think, since logpoints are really useful, they deserve a default keybinding. This would decrease the entry threshold.
4. Invoking the Add Logpoint command twice has no useful effect. If bound to a keybinding, the keybinding is wasted if the line already has a logpoint.
5. Logpoints are currently inserted at the current cursor column. You can even add multiple logpoints per line. I don't think this is intended.

I think it would be cool if the inline editor for logpoints would stay open the entire time. This would fix 1) and 2). An inline editor next to the line would be even cooler (like an editable "after" text decoration)

[isidorn]

Thanks for the suggestions, we might revisit this in the future.
3. there are too many default keybdinign in vscode, and we will not add a new one for add logpoint since users can change that easily
5. It is intended to respect the column, if the debug exetension can not support this they will update the logpoint to not respect the column
6. They will not stay open all the time that would make them too noisy

Other suggestions I think make sense. Thanks!

[hediet]

Thanks for your feedback!

Im fine with 3). However 5) is somewhat broken currently:

You should not be able to do that ;) You can't do that with plain breakpoints.

As for 6), I think a little noise is not wrong here. Logpoints should be temporary anyways, as they modify how the application behaves (yes, they can have side effects). Imo they are the fast way to insert temporary console.logs. If you would add a console.log, you would also get another line (but need to recompile your app).

I think it is much more important to quickly edit logpoints rather than making them invisble. If you debug something using logpoints, these logpoints are your center of attention and I would like to change them easily and see what they print.

A debug run may succeed, but fail with logpoints. So its very important to be aware of the logpoints (as well as conditional breakpoints). However, I guess, due to UX, logpoints are not used often anyways (do you have telemetry for how often they are used?). So even if it would be noiser, it might increase their usage.

I think with adjusting the colors (like making everything gray in this inline thing, including the top and bottom separator lines), you could reduce the noise.

[isidorn]

@hediet if you find time and if you are passionate about this I can provide pointers. Just let me know!

[roblourens]

5- "Add Logpoint" works the same as "Add inline breakpoint". Would you rather have two commands - "Add Inline Logpoint" with the current behavior and "Add Logpoint" which just adds it to the line? Do you want it to actually be "Toggle Logpoint"? Really the issue to me is that we don't have a way to remove inline breakpoints in general, and we also don't have a way to edit existing conditional/logpoints with a command. My preference would be that on the second invocation of the command, it edits the existing logpoint.

6- I wouldn't like this. I'd be open to something with a setting that keeps those editors open but I wouldn't make it the default.

An inline editor next to the line would be even cooler

This is interesting. But have to make sure it can't be pushed out of view by a long line of text

[vscodenpa]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!