Supporting multiple REPL modes and a switcher

[ViralBShah]

I often find myself using @everywhere ... and keep thinking that it would be great to have a parallel repl that automatically runs everything on every node.

Since the discussion that follows is about multiple repl modes, I will open a separate issue for the original parallel repl. -- VBS

[vtjnash]

To allow a rampant increase in the number of REPL modes (I made a list one day with Jeff and came up with at least a dozen plausible modes), would people be supportive of the following idea:

Replace the ; mode (currently cmd), with a mode switching meta-prompt from which all other modes are accessed via additional key-presses for unique prefixes, or enter. (Thus accessing the shell would become ;;). The prompt for this mode switcher meta-prompt would be a list of all of the available modes, for example:

0. julia
?. help
;. shell
@. everywhere
c. Cxx REPL
d. Julia Debugger
> @

@everywhere> 

^{_{[ and of course ( would drop you into a secret s-expr Julia REPL :) ]}}

[tkelman]

I like the sound of that. Assuming the API's for creating and registering new modes get documented a little more thoroughly than what we have now... And multiple packages trying to register the same key for different modes should be an obvious error.

[StefanKarpinski]

I do think we should have REPL-mode selection mode, but I also think help mode should continue to be entered with the ? since that's something people who are new will try.

[vtjnash]

@StefanKarpinski yes, i meant only that <;><?> would work in addition to <?>

[StefanKarpinski]

Ah, got it. Then yes, this seems like what we should do.

[ScottPJones]

Unfortunately, changing ; in that way would probably annoy lots of users.
My colleagues and I constantly use ; to do quick shell commands from the REPL.
Having to do ;; and have something flashing on the screen would not be good.

The idea is a good one though, could another character be used to intro the REPL menu, and leave
the current ; and ? behaviours alone?

Maybe one of #, /, \, ], <, >?

Also, maybe + for C++, and c for C (Keno told me at JuliaCon that it would be trivial for him to add a C mode REPL)

0) julia
?) help
;) shell
@) everywhere
c) C
+) C++
d) debugger

Finally, I think that any mode gotten into by this menu should be sticky, even the ? and ; modes.

[timholy]

I think a closing delimiter, ), ], or }, might be about the only free choices left. All the others mean something already, and can be in the first position. Or a control character? That has issues too, of course.

Another option would be to require ;;, but to schedule printing the menu of options 200ms or so into the future, aborting if the user has already made the choice through a 2nd character. That way someone who presses ;; or ;c quickly won't be bothered with the menu.

Overall +1 for this idea. I also think I like Scott's suggestion that shell- and other modes should be sticky. Not sure how I feel about help, though.

[StefanKarpinski]

I like ] – it doesn't require shift and isn't too far from the home keys and it's association with arrays kind of makes it sensible as something that gives you a choice of an "array" of REPL modes.

I agree about wanting to retain ; for shell mode, although when I was thinking through this, I kind of figured that if REPL modes become sticky, the easiness of reaching shell mode might be less important. Maybe modes reached by ? and ; should be non-sticky while ]? and ]; would be sticky versions (and sticky for the other modes too).

[ScottPJones]

That's what I meant, ; & ? would stay as they are, non-sticky, but ]; would be sticky.
+1 for Stefan's choice of ]

[StefanKarpinski]

Cool – that seems like a pretty good general arrangement.

[ScottPJones]

I'm sure Gerry Sussman would love the super secret ]( REPL 😀

[vtjnash]

Also, maybe + for C++, and c for C

as i said, there are well over a dozen possible modes (actually closer to two dozen). i listed the 6 most common for an example.

My colleagues and I constantly use ; to do quick shell commands from the REPL.

the parsing of shell-meta characters (like quotes and variables) is very buggy right now (#10120), so i would probably use this change as an opportunity to modify it's behavior to be less unpredictable

]

the risk with this characters is that a mistake in typing an array literal (or pasting it in on a terminal that doesn't have copy/paste delimiters) could send you off into a new mode (since it's not uncommon to put a newline before the closing bracket) -- i think that is an acceptable risk, however.

[ScottPJones]

as i said, there are well over a dozen possible modes (actually closer to two dozen). i listed the 6 most common for an example.

Is there an issue which lists all of the potentially useful REPL modes? Sounds interesting.

the parsing of shell->meta characters (like quotes and variables) is very buggy right now (#10120), so i would probably use this change as an opportunity to modify it's behavior to be less unpredictable

That would be good - for our limited use (mostly checking things quickly with ls/more/grep/man)
we really haven't had many problems.

the risk with this characters is that a mistake in typing an array literal (or pasting it in on a terminal that doesn't have copy/paste delimiters) could send you off into a new mode (since it's not uncommon to put a newline before the closing bracket) -- i think that is an acceptable risk, however.

I don't think the paste code would hit this - but that can be checked for, to not treat ] in copy/paste as this menu starter. I also think that when you are entering an expression, it wouldn't hit the check for ] as the first character either. If you try it at the REPL now, ? and ; don't try to switch modes if you are entering an expression, even if at the beginning of a line.

[PallHaraldsson]

@ScottPJones "Unfortunately, changing ; in that way would probably annoy lots of users."

While ; is legal in the shell, it's not helpful to start with, right? Maybe one ; could get the shell, but only if another ; is not entered? If another ; then that would trigger a prompt.

[Are there some other chars that are never useful, as first char, in the shell (and across shells, I'm not sure if same would apply to e.g. PowerShell) that could trigger something?]

[StefanKarpinski]

Considering this accepted with ] as the escape key for the menu.

[ViralBShah]

We need to rethink the @everywhere and how our distributed computing model is - before worrying about such a mode.