https://bugs.kde.org/show_bug.cgi?id=505521
--- Comment #2 from Aario <aario.i...@gmail.com> --- Hello, I've investigated this issue further by compiling Kate from source and tracing the debugger's execution flow. I have submitted a Merge Request (!1797) that resolves the issue by improving the user experience. **Problem Analysis:** The root cause is how the debugger configuration is gathered for DAP-based debuggers like `debugpy`. 1. The `ConfigView::currentDAPTarget()` method in `addons/gdbplugin/configview.cpp` reads the executable path directly from the `m_executable` QLineEdit widget. 2. For interpreted languages like Python, a user often won't have anything in this box, expecting the IDE to use the currently open file. 3. This results in an empty string being passed as the `program` argument to the `DapBackend`, which causes the `debugpy` adapter to exit with the `Error: missing target` message. 4. This backend crash then causes the briefly-enabled debugger UI to immediately become disabled again, creating a very confusing "catch-22" for the user. **Proposed Solution in MR !1797:** My patch fixes this by making the UI much more instructive: 1. **In `configview.cpp`:** The `currentDAPTarget()` method now checks if the executable path is empty. If it is, it displays a `QMessageBox` that clearly instructs the user to set the target path in the debugger settings. It then signals that the launch should be aborted. 2. **In `plugin_kategdb.cpp`:** The `slotDebug()` method now checks for this failure signal from `currentDAPTarget()` and cleanly aborts the launch process before the backend is even started. This approach prevents the confusing backend error and directly guides the user on the correct workflow for configuring a debug target. It makes the behavior clear and intentional. Thank you for your consideration. -- You are receiving this mail because: You are watching all bug changes.
