UI review: jshell commands

[Jan Lahoda]

On 29.6.2015 19:43, Brian Goetz wrote:
> Going over the / commands in jshell.
>
> 1.  Are we sure /help is complete?  I have not been able to determine it
> is not, but we should review that it is (ideally, deriving the /help
> text and the / command parsing from the same data structures.)

The commands are stored in JShellTool.commands map, and all of 
processing, help and completion use that map. So these should be 
consistent. One exception is the /<n> and /-<n> commands - these are 
processed separately (but still have an entry in the commands map, to 
get help). Another exception is the /debug command which is hidden from 
help and completion. For all other commands, all the features should be 
using the commands map.

Jan

>
> 2.  I recommend we drop the one-letter shortcuts, for several reasons:
>
>   - Such tricks always cause evolution problems.  One day, we'll add a
> new command whose first letter conflicts with that of an existing
> command, and which arguably has a superior claim to that short form.
>
>   - Tab-completion works against / commands.  So users looking to save
> keystrokes can use tab completion; the one-letter version now saves only
> the tab keystroke.
>
>   - The commands are not that frequently typed, compared to evaluating
> expressions.  So the extra keystroke savings (especially given tab
> completion) are not worth it.
>
> In short, I don't think they pull their weight.
>
> 3.  I don't think we ever came to consensus on /edit.  Right now, the
> popup editor says "experimental"; did we declare success or failure on
> this experiment?  I thought we were leaning towards dropping it.
>
> 4.  The /list behavior is a little confusing until you understand it.
> Perhaps the display should include a one-line header to the effect of "n
> implicit entries, type /list all to see", so that users won't be
> confused as to why the first entry is 9 and not 1.
>
> 5.  /drop name.  For most droppable things, "name" is a nice shortcut,
> and the interactive message we get when a method is overloaded is a fine
> compromise (rather than making the syntax more complicated.)  But, it
> may not be obvious the first time that the user is supposed to type
> "/drop 12" when presented with a list of candidate IDs.  The
> disambiguation text could guide the user to this a little better.
>
> 6.  /drop import.  I am not sure how to drop an import, but there needs
> to be a way to do this (otherwise, a mistaken import taints the
> session.)  I tried /drop id with the import id, and didn't get an error
> message, but it didn't have the effect of dropping the import, either.
>
> 7.  /open.  If I enter some expressions (e.g., 1+1), /save it, and then
> /open that, I don't see the expressions being printed as they are being
> re-evaluated.  I realize that /open is mostly for pulling in canned
> declarations, but I found the lack of printing out any notifications
> confusing.
>
> 8.  /methods.  I was a little surprised that I didn't get the sources
> for methods I'd typed in.  Perhaps an option on /methods to get the
> source too?  Ditto for classes.  (Also, /classes lists the names but not
> the generic type variables, which is part of the signature -- so I get
> signatures for methods but not for classes.)
>
> 9.  /reset.  Should mention that it re-reads the startup file, so the
> state is reset to the as-started state, not the "empty" state.
>
> 10.  /prompt.  If we're going to support customization of the prompt,
> then we should allow the user to select a prompt with "/prompt repl> "
>
> 11.  /classpath.  No way to *list* the class path or to *remove* an
> entry from the class path.
>
> 12.  I like the /n, /-n, and /! commands.  We had discussed aligning the
> temporary variable numbers with snippet id's, so an expression snippet
> whose id is 33 would assign to temporary $33.  The only weirdness with
> this is that people would be initially confused that the first temporary
> var is $9 and not $1, since we treat the startup commands as if they
> were input by the user.
>
>