RFC single key press to end "show output"

[gsigh]

Adds new 'show_output' config option. Remains backwards compatible, uses Python's input(3) by default. Extends that to also accept single key presses when configured. Should increase usability when 'o' and SPACE are as acceptable as ENTER is, which is rather distant from 'o'.

You can tell how this started with a quick local hack. Then grew bigger fast when I considered upstreaming. Became a little monster by now. The commit message provides details on the approach, and lists issues of the current implementation. This PR is meant to gather feedback.

Lack of doc update and UI adjustment is the biggest drawback. Just tell me your preference for more or fewer options, maybe point out which places need adjustment as new options are introduced. And I will improve that v1 to make it more acceptable.

Remaining text is the one commit's message, for your reference.

Introduce the 'show_output' config option, pass its value from the debugger's .show_output() method to the StoppedScreen class. Default to the 'python_input' selection for backwards compatibility. Support 'single_key' as an alternative, which accepts additional optional keywords: 'silent' to not prompt for key presses, and several sets of terminating key presses like 'o_space_enter', 'enter_only', or 'any_key' to reduce behavioural changes from to earlier versions.

show_output = python_input
show_output = single_key
show_output = single_key silent o_space_enter

In the absence of terminating key press specs, any key press leaves the output screen. The implementation uses Python select(3) which may not work with stdin on Windows. The StoppedScreen implementation lends itself to more keywords and other ways of getting user input if desired.

TODO

• Config file handling is incomplete. Implements the keyword and its default value, but lacks documentation and UI controls.
• Move NonBlockingConsole to a better location, common support or platform dependent?
• Drop diagnostics.
• Is it confusing to have too many configuration options? Just have "single key, any key" as one boolean choice while the default is the input(3) invocation that is portable to all platforms?
• Maybe adjust Python style where required.

[inducer]

Thanks for making this! As it stands, I'll admit I'm not a huge fan. This seems like a fairly fiddly approach to a (subjectively) minor annoyance. There might also be a simpler solution: why not add "Enter" as a key to show the console? IIRC, that's not currently mapped. Maybe that's hare-brained for some reason? Not sure.

[gsigh]

Oh I can totally see how the v1 implementation was stupid and ugly. :) But I strongly believe that the approach improves usability. Annoyance with earlier behaviour was beyond minor, and involved multiple aspects.

One was the "reachability" of the ENTER key: o is immediately at your finger tips, the same way as are next, step, continue, till, etc. Enter is somewhere more distant, makes you leave the current position of your hand, puts more strain.

The other aspect that made me wish for different behaviour after very short use of pudb was the screen clutter. When you step through code, you may know when to expect output, and have a look. When you "next" over complex call hierarchies, then you don't know when to expect output. That's when the prompt quickly accumulates on screen, just for looking. And scrolls content off screen that you may want to keep there. Since users interactively control the debugger, they should know when they have entered output mode, and that another key press leaves that view. There is not much information in that prompt.

So it's the combination of single key and silent that increases usability from my perspective in ways that should be desirable to other users as well. Try it, hit the o and ENTER combination a few times. Then toggle the switch and hit o a few times, to see the difference. Gotta experience that to notice, I believe. It's not that the current behaviour is wrong, it's just a little too clumsy. But shall remain available and the default for its greater portability. Single key should remain an option, and only "affect" users who enable it and thus are aware.

I can totally understand how you are not a friend of the first implementation. Have pushed something of lesser complexity, less confusing to users. See the diff from @{u} to HEAD for easier review. When you ACK then I can squash and submit v2. Should I have missed some UI update, help text, doc paragraph, then I will provide that after learning what's missing.

Did I mention how much I like pudb in all other respects, after only recently learning it exists? Finally a debugger that just works, comes with great features and is quick and responsive to use, a joy with its sane key bindings. It's such a difference to what I tried to use before, and a very positive one. If that single key press change is the only "problem" that I wanted to address ... says something about your project. :)

[gsigh]

You were wondering about the appropriateness of binding the Enter key. I'd suggest to not do that (not in the project, not with some "action", not by default). Users may want to use Enter as a means to scroll text by one line, similar to cursor down. As they may be doing with $PAGER or $EDITOR already in other contexts.

[inducer]

Thanks for revising the PR. I'm warming to this. A few thoughts:

• Why make this a setting? IMO, the implementation should be good enough to be the default, and automatically fall back to the previous behavior when not possible (e.g. Windows)?
• Is a prompt needed? ("Press any key to return"?) Or is "any key" sufficiently discoverable?

[gsigh]

Had not dared to make "so changed a behaviour" the project's default. :) Also had been hesitant to confront users with either single press or ENTER required for the same version of PuDB but depending on their platform. Then did more research.

Was aware that Python's select(3) module is universally available, but documents that Windows exclusively supports sockets. Was not aware that tty(3) is universally available, but depends on termios(3) (Python and libc) which is documented to only support Unix (actually: POSIX supporting Unix systems).

Then did more reading, came up with something that might be acceptable to the project. Moved "non-buffered console" to lowlevel, might as well be ui tools. Have put Python imports under sys.platform checks, did a lot of guessing there. Am falling back to calling input() when neither select nor msvcrt are available. Could be GoodEnough(TM) when only Webassembly and other non-desktop systems aren't covered? Is straight forward to adjust or extend, remains internal to low level support code.

This is untested outside of Linux. Needs help and/or feedback from other users. But I like what I could come up with so far. Maybe imports must go under additional try/except. A problem would be when modules successfully load and don't work as expected. That's when automatic detection of a useful approach is impossbile. Except for learning about that and tweaking more sys.platform checks. Could be good?

As usual, diff against @{u} for readability, will squash and cleanup when the direction is agreed on.

[gsigh]

Have checked the single key press abstraction's operation on other platforms than Linux/Unix. Worked here on Windows in native CMD and PS environments, in Cygwin, and (of course, it's Debian) in WSL. Was known to work on Linux before, should work on any POSIX supporting Unix (which covers the BSDs, also covers MacOS). So shall be good out of the box for all major desktop systems. And doesn't require a config item any longer.

Still would be nice if more users ran the test on their respective platforms. See the nonbufferedconsole.py script in the project root for easy access. The only Python supported platform that still requires the backwards compatible input() call is Webassembly. The "emscripten" exclusion is a guess of mine. And I don't pretend to know which platforms PuDB officially attempts to support. Yet the order of "known unsupported, Windows, and all others" looks plausible to me now.

When you find this implementation agreeable, then I shall squash and provide a proper message, it all fits into a single commit after you helped me reduce the monster volume of the first approach that no doubt was heavily over complicated. :) Have kept amending so far to keep this PR and its history in place, and so that others can compare approaches that were taken.

[gsigh]

Did the cleanup, squash and message rephrase in the v2 branch. Will open a PR for that and close this one. Searched again with 'git grep -i enter' and 'git grep -i output', could not spot doc locations that need adjustment. So am considering the recent submission complete, and the form it took shall have become acceptable. Did address all your feedback, and cannot see something else missing.

[gsigh]

Closing the PR, has been re-submitted cleanly in PR 674.