JShell tool: remove or keep default Edit Pad editor?

[Som Snytt]

Scala REPL uses EDITOR, but I'm going to try a plug-in approach. But it has
to be easy to fetch the plug-in.

The alternative Ammonite REPL makes downloading dependencies easy. The
Scala REPL receives black marks for being an awkward download for newbies,
with no story for dependencies unless run under the sbt build tool (as `sbt
console`), which is also awkward. Some users prefer the worksheet available
in the IDEs in any case.

The other possible integration point for Scala is the Ensime project, which
lets emacs/vi/et al talk to a resident compiler and benefit from
autocomplete and so on.

Ammonite avoids baked-in features, especially half-baked. I'm hoping for
editing support for Scala REPL as a separate module; the Scala project has
been farming out bits to semi-autonomous projects, as a way to reduce
download size and maintenance burden, including the cost of maintaining
suboptimal code.

Scala REPL is also the basis for Spark shell, which has special needs for
how snippets are translated to compilable units; that's another example of
a feature that would have benefited from pluggability.

HTH. I've been impressed how jshell issues sound familiar from the Scala
experience. Except the naming problem. The Scala REPL never had an
interesting name.


On Tue, Oct 11, 2016 at 5:51 PM, Robert Field <robert.field at oracle.com>
wrote:

>
> On 10/11/16 16:09, mark.reinhold at oracle.com wrote:
>
>> 2016/10/10 17:31:35 -0700, paul.sandoz at oracle.com:
>>
>>> IMO i think you should drop it, for many of the reasons you have
>>> stated. I suspect we may come to regret this dependency later on.
>>>
>> I agree.
>>
>>      $ ls -l java.desktop.jmod jdk.jshell.jmod
>>      -rw-r--r-- 1 mr green  12M 2016-10-09 03:55 java.desktop.jmod
>>      -rw-r--r-- 1 mr green 387K 2016-10-09 03:55 jdk.jshell.jmod
>>      $
>>
>> It sure would be nice to be able to link a custom image that contains
>> jdk.jshell without dragging in all of java.desktop, as it does now.
>>
>> One approach for an out of the box solution is to split out the editor
>>> functionality into a separate module and for jshell to define a
>>> service provider interface. Thereby on a full JDK distribution you can
>>> the same functionality but on a more minimal distribution it is not
>>> present.
>>>
>> That would be the "modular" way to do it.
>>
>
> That would certainly be doable.  If the critical concern is module
> boundaries.  But that exposes the Edit Pad to use outside of jshell -- is
> that an issue?
>
> The Edit Pad doesn't have any particularly interesting differences from
> the use of any external editor -- except that we know it exists.  Any
> mechanism by which we could know where an editor was would work.
>
>
>> Have you considered, at least on Unix systems, supporting the EDITOR
>> environment variable?  Yes, it might be platform-specific, but it's an
>> incredibly handy and reasonably standard way to tell random programs how
>> to use the editor of your choice.
>>
>
> Was tempted.  The jshell tool suspends the REPL while in the editor (so
> they don't clash).  However some editors return immediately -- there is a
> -wait option on /set editor for this case.  But of course, coming from
> EDITOR there is no way to know if it needed. Between that, the platform
> specific aspect, and how it would interact with /set and Preferences -- it
> seemed a bit convoluted and shaky.  Still an option but it doesn't solve
> the problem -- just another finger in the dike.
>
>
>> - Mark
>>
>
> Thanks,
> Robert
>
>