UI review: jshell commands

[Brian Goetz]

>> 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.
>
> We could, but that seems noisy — though I guess it would only be in
> default feedback mode (but the thinking is that is where most people
> will live).

Something like:

repl> /list

     [8 implicit entries, type /list all to see]
     9: int a = 1
     10: int b = 2
     11: a + b

This doesn't seem unreasonably noisy?  Is there a less noisy way to get 
people to realize that there *are* implicit entries?  Or just make /list 
all the default, maybe with some indication they are implicit:

repl> /list

     1: [ import java.util.* ]
     2: [ more implicit entries ]
     ...
     9: int a = 1
     10: int b = 2
     11: a + b

My concern is that I want the user to quickly internalize that a) there 
*is* a startup file, and b) that things read from the startup file are 
handled "as if" the user typed them.  Once you know these things, its 
not surprising, but until you do, it is.  How can we help the user get here?

> I’ve been thinking that the welcome message, instead of advertising
> /help, would suggest a /intro — which would give a pocket intro
> including discussing /help, would talk about anything surprising, like
> this, and describe setting feedback mode, and how to save start-up
> definitions/commands.

Seems like a good idea.  (Whatever text it displays should also be 
available some other way, such as a "getting started" doc; no point in 
duplicating intro text between the program and the documentation.)

>> 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.
>
> Hmmm, this interacts with the ongoing level of feedback question, but
> depending on what you are opening this could be very noisy.

Could be.  I was just a little surprised to see nothing.

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

Which is more of the "help them to internalize the model quickly."

> I still think that is a good idea.  There are a few other little curly
> bits:  the user has defined a variable $2 we skip id 2, do we still
> define variables for snippets with no value, if so, what type?  A
> snippet matching an existing snippet signature keeps the same Key and
> thus id, but then it should use the same temp variable and, oops, the
> type may have changed. …

I think we should only define a temp for a snippet that is a non-void 
expression.  If the user has defined $2, we can step on it; the 
side-effect message could even reflect this:

(overwrote existing variable $2 with new temporary variable of type int)

instead of

(created temporary variable $2 of type int)

It's very much a corner case, and users who are attracted to that corner 
will quickly learn to not define temps whose name matches $nnn.