Proposal - A Built-in Text-based Debugger UI

[st0012]

I want to propose a built-in Text UI that's similar to GDB's TUI, which has one key feature: having multiple windows to display different information at the same time. For example:

• Variables
• Source code
• Backtrace

Also, it may be able to display debug.gem-specific output as well, like:

• Information about replay debugging
• Tracer output

And windows should support these operations:

• Focus on a certain window and scroll its content
• Configurable information

As for features like key-bindings, layout, custom color schemes...etc. They'll be nice to have but probably aren't necessary in the first few versions.

(In the long-term, I hope the UI can be close to ruby_jard's or provide APIs for community-based UIs)

Usage

By default the debugger UI shouldn't be started. But users can use it with:

• tui on|off to open/close the UI.
  • GDB uses tui enable|disable but we already use on|off for trace and record commands.
• tui focus <num> to focus on a window.
• tui up|down <lines> for primitive scrolling.
• A new configuration option RUBY_DEBUG_ACTIVATE_UI - when it's set the UI will be activated whenever a breakpoint is triggered.

Why do we need a built-in UI while there's already DAP support?

• It'll be accessible to all Ruisysts: ATM, VSCode (used by 30~40% of the Rubyists) is the only editor that can work with this debugger via DAP. This means users of other editors can't access any debugger UI powered by this project. So if there's an UI bundled with this gem, all users will be able to use it.
  • It's not easy to support debugger UI for non-vscode editors atm. Because it usually requires:
    • DAP support from editor plugins (for vim users, it relies on plugins like vimspector).
    • Extra work to connect the DAP plugin and vscode-rdbg. For example, Question on integrating with vimspector vscode-rdbg#7
  • (Editor usage source: Rails survey 2020).
• It'll require zero or a minimum setup: Event if all major editors support DAP and work with this debugger, it'll still require different levels of setup + learning the editor's debugger commands to activate the debugger UI. But the built-in UI won't require any or much less of them.

When don't we let the community build it?

Although it'd be great to have a community-powered UI (or even multiple of them), there's no guarantee that someone will build one or keep maintaining one. So I think it's crucial to have one UI that's supported by the Ruby core.

Another reason is that this debugger needs to be not only thread-safe, but also ractor-safe. So anyone who builds the UI should also be well-awared of the development of Ractor and Ruby. Of course, the debugger can just provide ractor-safe APIs to the community and let the community build the UI. But to design those APIs properly it also requires at least an UI for testing.

Other notes

• I know the debugger still has other high-priority tasks for its release with Ruby 3.1 and it's not likely to support this before that. But it'd be great to see a basic TUI in the next year.
• In my very brief (one day) experiment, some refactorings like Use local variable instead of instance variable to store the current thread client #293 may be required to help simplify the implementation.
• I think https://github.com/Shopify/cli-ui will be a great source of inspiration for UI implementation.

[ko1]

It depends on the size.

[ko1]

My comment is, I think it is enough to have web-browser UI.

[st0012]

@ko1 I think having browser-based UI is great, but Text-based UI can not be replaced with browser-based ones. The purpose of having editor-based UI and texted-based UI is to see all the information we need in the current window (at least the current app). Having to switch to browser is inconvenient.

[ono-max]

Having to switch to browser is inconvenient.

Switching to the browser is one of the popular solutions. The default debugger of nodejs is the example.

[st0012]

It's a popular option doesn't mean it's a convenient one. As you documented in #315 description, it takes 3 steps between terminal and chrome to start the debugger UI. But for TUI, it takes just one command.

Another problem is that not every user uses Chrome. Right now I use a chrome-based browser called Sidekick (which I recommend), so I think your PR can work for my setup. But I only switched to it until 6 months ago. Before then I only used safari for 3 or 4 years. So just like DAP support, it only serves a certain portion of Rubyists.

Again, I'm not saying we don't need brower-based UI. It's a great addition and your work is amazing 👍. I just don't think it's a replacement for text-based UI.

[ono-max]

I see. Thank you for explaining to me 👍

[mzagaja]

As a user I was very excited to see this proposal. I think it would make Ruby debugging even better, especially for folks like me that do not use VSCode.