[ESS] feature request: shell support

[Vitalie Spinu]

Hi Tyler, 

Great job. I like your clean code and I very much welcome your zeal for
writing an universal process handling library. But ... let's not take it
lightly and reinvent all the wheels again and again. There are a
milliard of small things to be considered like, multiple processes,
completion and auto-completion eldoc, help, debugger, (visible invisible
evaluation), process' "busyness" status and image/notebook handling.


 >>> Tyler Smith on Mon, 28 Oct 2013 12:36:46 -0400 wrote:

 > Hi,

[...]


 > I initially thought about writing this as an extension of ESS, but was
 > intimidated by the size and complexity of the ESS code. 

Most of the code is complex for a reason. A lot of subtle and
undocumented tweaks are there. If you start building ESS like software
from scratch you will end up reinventing most of it the hard way.

 > It may be possible to isolate the process communication stuff as a
 > separate library, so you could use the same base for bash and grass.

Nobody wants to do double work, especially of this magnitude. If you are
really into it, I would propose the following plan. I can
isolate/rewrite ESS process handling and document a preliminary api for
simple process text based communication. Then we can carefully device a
grand plan for next year or so. There are some brilliant guys out there
working on process handling for different modes (ruby mode and geiser
are new attempts). We should definitely call in as many people as we
can.

I have been on this idea for a while, and concluded that the best way to
go about it is mode-local.el. It takes away all the subtleties of
keeping mode specific variables. We do that in ESS as with
ess-customize-alist, but at a very basic level. Mode-local.el handles
inheritance and that is a big deal.

The only thing that mode-local.el is missing is the custom
interface. Users should be able to customize mode specific variables. We
are doing that in ESS manually so far (like ess-R-var-name for a global
ess-var-name).

If you are interested and you think you will have time (a lot of it) we
can talk much more and in greater detail.

An important thing to consider is the provision for slime-like socket
based interface. Clojure nrepl should be carefully examined.

Best thing would be to completely reuse nrepl or slime communication
protocols.

If we are successfull at this attempt ESS will become a simple
collection of statistical modes, and may be GRASS will become part of
it;). That would be awesome.


   Vitalie