I've been using RemedyBG alongside 10x editor as a Visual Studio replacement. 10x allows custom python scripts so I use the command line options in RemedyBG to allow my text editor to launch/stop the process or to add/remove breakpoints. This works well, but the process is all one way. If I change a breakpoint in RemedyBG, there is no way for the text editor to know about it. Also, the command line method seems to break down if I send too many commands at once (say, to set lots of breakpoints).

I'm wondering if we can get a more complete method of setting and getting the state of RemedyBG? Something that lets you set all breakpoints at once, and that lets you query for the current state of breakpoints. It would also be nice to drive the multiple configurations options in the same way.

TCP sockets or shared file mapping would possibly be the best option for fast comms, but possibly a simpler solution could work via writing and reading session files?

This certainly comes up a lot and as such has a pretty high-priority. I currently plan on using named-pipes for bi-directional IPC (though I may change my mind when I actually go to implement it).

Prior message on Discord where this was brought up, for reference:

I've been thinking through enhancements to external control for RemedyBG (for editors like 4coder, 10x, etc. as well as for creating better tests internally)

Right now, as some of you know, you can drive Remedy via the command line in a write-only fashion. This is done by forwarding command-line arguments from a second instance of RemedyBG to the initial instance using a combination of named shared memory and a registered window message. This works okay but isn't ideal.

Was thinking about adding named pipes for i) sending commands to remedybg (e.g. start-debugging, add-breakpoint) ii) receiving async notifications (e.g., breakpoint hit, step-out complete, etc.) and other UI events (e.g., breakpoint-added) iii) receiving OutputDebugStrings (if anyone would want this). This is basically the three channel setup I had when Remedy was a Vim plugin except that the vim job system uses stdin, stdout, and stderr respectively. Could probably combine i) and ii) using a bi-directional pipe if that made more sense.