Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8177076

jshell tool: usability of completion


    • Subcomponent:
    • Resolved In Build:
    • Verification:



        The <fix> shortcut key is too difficult to discover and learn because it has differing bindings on different platforms: Sometimes it is Alt-F1 and sometimes Alt-Return. The functions bound to <fix> are important to jshell's ease of use, but hidden in the documentation under the mysterious name "<fix>". Jshell also usese two portable, easily discoverable shortcut command keys, which are Tab and Shift-Tab.

        Recommendation: Jshell's shortcut functionality needs to be coalesced onto the two portable, discoverable, documentable keys that are available to it: Tab and Shift-Tab. Fortunately, this is simple enough to do, because existing Shift-Tab functions can just be bound to Tab itself, in the form of responses to multiple Tab presses (which yield escalating amounts of information to the user). The problem of non-portable shortcut bindings needs to solved another day when we have more time.

        This is urgent to fix now (P2), because users will train themselves one way or the other and we won't want to ask experienced users to retrain in JDK 10. Meanwhile new users today (and all users are new users today) are finding the awkward <fix> key hard to discover and use, which hurts jshell's usability out of the box.

        (There are a number of smaller usability problems which do not need fixing immediately. They are broken out as separate bugs or RFEs. Some of them are pointed out in the remainder of this bug text.)

        - The Alt-F1 <fix> key should be more eager to print a help message. For example, <fix><fix> (two in a row) or <fix>? should print a help line. Basically, if the thing can't make progress with the input after a <fix> key it should print a hint to the user.

        - There should be only one main key (Tab) which performs the workflow function of "either supply a completion or tell me my choices at this point". Currently Tab and Shift-Tab divide those choices. I love smart code completion, but I hate it when you have to try several different command keys to find the type of completion you want. (Intellij has this flaw for example, but Emacs does not.)

        - The UI interaction which ends "(y or n)" is deeply unsatisfying, because you have to think outside of your flow to satisfy the computer with a "y" or "n". It should say "(559 possibilities; press Tab to see them all)". If you press anything else than Tab, it should know you didn't care and immediately use whatever key you pressed to make progress. As the tool works now, it will ignore everything you type (including Control-C) until you give it the "y" or "n" it requires: A modal trap.

        Regarding completion: It is true that completion and documentation are different
        in concept, but in the flow of writing code they are the same kind of thing. The user is trying
        to type in the next few characters of the UI input, and either one or more characters can be
        inferred or there is a choice. At that point I don't care that Tab gives me the choice of identifier
        characters and Shift-Tab gives me a choice of expressions. In all cases I want the UI to
        either write the characters for me or else give me a menu of choices. And I think one command
        should do both. I don't one to type the "put in more characters please" command, have it
        fail, and then have to type the "give me the choices at this point" command. I want both
        bound to the same key, which I think of as the command for "make progress or tell me why I can't".


            Issue Links



                • Assignee:
                  jlahoda Jan Lahoda
                  rfield Robert Field
                • Votes:
                  0 Vote for this issue
                  8 Start watching this issue


                  • Created: