UI review: jshell commands

[Brian Goetz]

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.)

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.