So this is gonna be kind of obvious and probably already on the long term list of needs (like version 10), but the thing I’m missing most is debugging support and am wondering if there is any plans in this department?
I realize it can be an absolute nightmare…. but Microsoft/Vscode already has a protocol in place that standardizes how an IDE interacts with a debugger (Official page for Debug Adapter Protocol) and it seems like an obvious choice for an app with a small user base to hit the ground running. It’s got great support (obviously every debugger in vscode already has an implementation of it) and is well setup to grow. Doesn’t seem like they’ve made any changes to the protocol itself in a while, but that’s likely a sign of it’s maturity and makes it easier to keep up.
We are very much considering support for debuggers. It has been on our long term plans ever since launch, and mostly just comes down to “when we have time to do it.”
One caveat we found with the Debug Adapter Protocol: Many of the debuggers that use it are currently wrapped in VSCode-only extension packages (they aren’t separate packages in any way), and they make assumptions that they are running with VSCode only. This might prove challenging to quickly integrate them with another editor like Nova. This includes the DAP bindings for PHP’s Xdebug, wrappers for debugging in Chrome and Firefox, among others. They could likely be modified to work, with some effort from those projects’ contributors.
However, other projects, like debugpy, are very much good citizens of the protocol and are IDE-agnostic.
Totally fair. DAP as an ideal isn’t really met when the wrappers to make it work aren’t written to separate the codebase that implements the protocol from the codebase that integrates it into the IDE. Clearly Microsoft themselves as the people heading the initiative are being careful (since as you point out debugpy is written with good code separated), but for other developers it seems like they might prioritize getting something up and running when there was really only 1 IDE using it (2 if you count VSCodium).
I am seeing signs of more platforms integrating it such as:
but there isn’t many. I do believe it’s the future but it also seems like it’s stagnated a bit.
Anyway, it’s at least a starting point, and for plugins with somewhat interwoven code… I suspect the VScode side of the equation isn’t nearly as large as the DAP side to extract out for anyone in your fine community of devs wanting to take on the challenge.
Just from a quick cursory look (I don’t work in Ruby, so I’m a layman just looking), it doesn’t appear that this project integrates aDebug Adapter Protocol bindings of any kind, but it would certainly be possible to wrap it as such (if someone hasn’t done so already).
I see there’s a VSCode wrapper for this already, so hopefully that work would be reusable!
Monterey seems to have broken the UI of MacGDBp, a tool on which I relied extensively in my workflow, so I’ve been researching the feasibility of implementing debugging straight in Nova. The DBGP protocol is fairly simple and well-documented, so I think that part of it is within my capabilities. In terms of the Nova API, for breakpoints, we don’t have a way to listen for clicks or set markers (other than errors/warnings) in the line number gutter, but we could just use a TreeView to show a list of set breakpoints and have the “create new breakpoint here” command figure out what line the cursor is currently on.
From what I can tell the biggest hang-up is that there doesn’t seem to be a way to just connect straight to a socket via a low-level TCP connection. The best possible workaround that I can think of so far, though I haven’t tested the feasibility, is starting up a netcat process and sending data back and forth with that. It’s gross but it might work.
Unfortunately (or fortunately) I’m apparently going to have less paid work than I need this month so I might be able to play with this in the coming weeks and see how far I can get.
As for DAP, I’ve never heard of it before. Did Microsoft just reinvent GDBP, or does it work better?
Before you get too far into things, I will explicitly say: Panic is actively working on Debugger support (including, specifically, wrapping DBGp for PHP) for a future version of Nova. Our support is based entirely around the Debug Adapter Protocol with custom adapters for some of our target languages (like DBGp).
Just a friendly FYI in case you might put a ton of work into such at the same time we are adding these features to Nova’s core. We don’t have a specific target date for this version of Nova (as debugging support is big), but our hope is to have it ready sometime early next year.
I’m glad to hear that! I look forward to seeing that feature in action.
That said, I think I’m gonna keep working on my implementation of it, partly because it’s fun working on something so hilariously hacky (I literally laugh out loud at the monster I’m creating at times) and partly because I’m learning some cool stuff which could be applicable to a more serious extension in the future. Most likely I’ll never actually release this thing, but if I do I’ll be sure to add text at the top of the README that my extension shouldn’t be taken too seriously and that something better is on the way.
The closed beta is out for a while, any news on the progress? No release date, merely thumbs up (on track) or thumbs down (blockers remain, don’t hold your breath).
The most recent beta from last week was billed as the “final Nova 9 beta” and was released only about a week after the previous beta, so Soon™ seems to be the answer. There’s undoubtedly much work to do to get ready for a big release like this (documentation, etc.).
For anyone curious, there’s a Panic Library page on what debugging is included in Nova 9:
Updates to the Extensions API documentation with how to connect to Nova’s debug client will hopefully follow the version 9 release. For now, anyone hoping to add support for their language’s debugger can inspect the Nova 9 app contents and try to mimic what Panic did with their supported debuggers.
We don’t have a specific target date for this version of Nova (as debugging support is big), but our hope is to have it ready sometime early next year.
Most likely I’ll never actually release this thing, but if I do I’ll be sure to add text at the top of the README that my extension shouldn’t be taken too seriously and that something better is on the way.