JShell: ideas/opinion sought -- /edit with external editors which return immediately
michael.mueller at mueller-bruehl.de
Mon Aug 22 05:01:23 UTC 2016
+1 for option 4
a) If, and only if the editor process is started from within the JShell
then JShell will return to input when the editor process ends.
In all cases:
if the user starts the /edit then JShell does not accept any input
except a special Escape character (e.g. the Esc key) until a) or that
special input. In case of that special input JShell queries "Quit edit
mode (Yn)?" If the user answers "y", then JShell returns to its prompt.
As long as JShell is in "waiting" mode, it observes any change to the
file and runs the code snippets if a change is detected.
If the editing process is started from within the JShell and the user
keys in the escape character, then JShell will stop the editing process.
Herzliche Grüße - Best Regards,
Read my books
"Web Development with Java and JSF": https://leanpub.com/jsf
"Java Lambdas und (parallel) Streams" Deutsche Ausgabe:
"Java Lambdas and (parallel) Streams" English edition:
On 08/22/2016 03:49 AM, Robert Field wrote:
> 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:
> 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.'
More information about the kulla-dev