Consider adding breakpoints and debugging just like full VSCode can

[Meai]

I dont see any reason why this feature should be missing from monaco-editor.

[rcjsuen]

@Meai What do you mean by debugging support exactly? Monaco runs on the browser. It's not going to have access to your C++ native executable that's on your local disk.

Or did you mean you just want API to draw a breakpoint icon of some sort in the editor's margins?

[Meai1]

@rcjsuen I mean that monaco-editor should give me gui / hooks that I can tap into to make a debugger gui appear including the stepping support and locals window.

Debugging: Debugging just means that there is some kind of database that will be queried on a line by line basis with a GUI on top. That information could be queried by means of a protocol, which could be over a network or just by reading from a string in memory.

Requirement: monaco-editor should offer some generic gui that shows locals, breakpoints, allows stepping.

Example: https://github.com/Microsoft/vscode-mock-debug This allows textual debugging of a .txt file. Why shouldn't that also be possible in monaco-editor? The textfile itself is just text. There isn't even any debug database necessary, yet I can "debug" it. I want that for monaco-editor too!

My Usecase: I built a code editor like dartpad / golang playground / rustlang playground for my custom language but now I want to offer debugging on top of that. So currently whenever a user presses 'run' for a given piece of code, I send his code via network to my server where it's run in a new docker container. I see no reason why the user shouldn't be able to connect and talk to that container so that he can get more than just the end result from that playground run. I want to give him the full debugging experience, while in the browser! monaco-editor just needs to give me the default debugging gui to fill out with data and allow me to step.

[AntonKrug]

I would like the debugs hooks as well. OpenOCD could be modified to use WebSockets and then actually browser could interact with even real hardware.

[lastmjs]

This could be useful to me as well. I'm currently using the ACE editor in a web application. I have a custom markup language that users can edit, and it can be manipulated from a JavaScript API from the ACE editor. It would be amazing to allow breakpoints to be set in the editor GUI to further ease the users' experience as they write and debug JavaScript directly in the editor.

[Jelledb]

+1 this can be very useful for me for the same reason @lastmjs stated.

[sec0ndhand]

yep, could totally use this. Looking at codemirror to implement since it isn't in monaco yet: https://codemirror.net/demo/marker.html

[akosyakov]

@sec0ndhand You should use monaco.editor.ICommonCodeEditor.deltaDecorations for setting markers in the gutter.

[sec0ndhand]

I wasn't looking for all of the features above, like stepping support and the locals window, I just wanted break points at least, and @akosyakov that is what I was looking for. Specifically for anyone else searching for debugging with monaco editor, this playground example shows the ability to set break points: Rendering Glyphs in the Margin

[shivajivarma]

+1

[vincentLiuxiang]

+1

[rebornix]

Our debugging component in VSCode uses official Monaco API to draw the breakpoints, conditional panel and inline evaluations, me personally prefer the debugging logic to be outside Monaco editor.

For anyone interested in how to implement the similar debug GUI in Monaco, you can either take a look at our VSCode Debug related code, or my fork of Firefox Dev Tools with Monaco embedded. With later, you can get an idea of how decorations and viewzones are used to draw those UI elements https://github.com/rebornix/debugger.html/blob/monaco/src/components/Editor/Breakpoint.js

[tejasrivastav]

Any guidelines on how to add contextmenu to the modelDecorations aka breakpoints.

+1 for this feature.

[tejasrivastav]

There is a private method on the editor instance which generates the GUI for the contextMenu. editor.getContributions("editor.contrib.contextmenu")._contextMenuService.showContextMenu(config)

[TehWardy]

Disclaimer: This is totally just a brain dump ... I also realise this is a huge ask but with modern roslyn API's in .Net and a little magic i've seen devs perform small miracles in the past so here's my 2p worth ...

We have a custom workflow engine that allows for blocks of code to be written in to the links between the activities in the flow as part of a visual designer experience. The engine runs the flow as an azure function execution by dynamically linking known activities together with dynamic functions generated from user input.

The workflow engine already talks to a signalr Hub in our API layer and streams logging information in real time to the web page the designer is loaded on.

The idea being ... I could (maybe) make a server side call / message send to "hold the execution and wait instructions on the hub connection". Then in the client code "hey here's a hub to which a running debug stream of messages will come from, talk through that and do your thing".

The specifics of course depend a lot on the debug information between the running process and the web page, I'm sort of hoping though that by telling the front end and the back end "hey guys, talk to each other through this hub" monaco's code can figure out the details.

In our case the workflow execution could be serialised in to a large block of code that contained the details of the entire execution which could be loaded in to monaco, so all I would need form the debugger stuff like "hey i'm on line x, here's your locals {json blob}" or something.

I imagine that's not trivial in itself ... then bolting on to that "ok step into" or "step over" ... there's also the issue of the function not living forever but that could be solved with using a docker container or something instead that has a longer lifecycle.

[hediet]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!