JShell: ideas/opinion sought -- /edit with external editors which return immediately

[Robert Field]

  When an external editor has been selected with '/set editor ...' and 
the /edit command is used:

     * until the editor exits, no jshell prompt is displayed and no 
input is accepted
     * a temp file is created containing the snippets selected for editing
     * the editor is launched with that temp file as its argument
     * until the editor exits the jshell tool watches the temp file for 
changes, entering any changes
     * when the editor exits, the jshell tool stops watching and the 
prompt is displayed again

Michael Mueller submitted this bug:

     https://bugs.openjdk.java.net/browse/JDK-8158738

pointing out that this scheme fails for many editors when there is an 
existing window (gedit, netbeans, nano, emacsclient -n, ...), Here I use 
gedit to illustrate the issue.

What is happening in this case is that the first time the gedit command 
is used it creates the window and waits for all windows to close before 
exiting. Subsequent calls to gedit add a pane for the file and return 
immediately. As a result, where the subsequent call is from a /edit 
command, the jshell tool assumes the editor has exited, stops watching 
the file, and queries for input with a prompt.

For gedit, this can be addressed by using the --wait or maybe better the 
--standalone option:

     /set editor gedit -s

There are several ways to resolve this issue:

(1) Add documentation to the '/set editor' command describing the 
requirement that the editor command not return until editing is complete.

(2) Change the behaviour of the /edit command to continually watch every 
temporary file that was ever opened. The concern with this is that then 
changes could be made from multiple angles at overlapping times: the 
jshell prompt, and multiple open editors. Changes in one would not be 
reflected in the others, allowing changes to be smashed. This might be 
acceptable because the same could occur in other contexts with multiple 
editors, though there would usually be notifications that the file had 
changed underneath you. Note: there is no primary "file" with which to 
do this in the jshell tool -- synthetically manufacturing one would be 
fraught with data loss peril. Another issue is that output would be 
coming from multiple threads -- while waiting (or typing) at the jshell 
prompt you would get notifications about editor changes " modified 
method m()".

(3) If (2) were considered appropriate, then it might be reasonable to 
take the next step, always return immediately from the /edit command, 
thus allowing jshell commands while in the editor.

(4) Michael Mueller suggests observing the jshell tool keyboard input 
'If the user presses Esc within the terminal, the JShell queries "Return 
to JShell?". If the user answers "y", then the JShell returns to its 
prompt.'

Thoughts?

-Robert