[ESS] feature request: shell support

[Stephen Eglen]

To throw another idea into the mix (for Christmas!).  I met with Stefan
Karpinski (a Julia developer) recently who suggested they had good
experience working with 'ipython' as a communication protocol between
Julia and the notebook viewer.  

As I understood 'ipython' is the name given to the interface that hooks
up 'backends' like Python and Julia with 'frontends' like a notebook
viewer (within a browser) or the Emacs frontend:
  http://tkf.github.io/emacs-ipython-notebook/

JSON is used to communicate data.  Is that efficient enough for our
purpose in the future if/when we get round to rewriting ESS to remove the
comint approach?

Stephen



On Tue, Oct 29 2013, Matt Landis wrote:

> I just wanted to add an enthusiastic +1 for the idea of universalizing
> ESS-style support for interacting with multiple process from multiple
> files, as Kasper put it.  Every time I start a project that will keep me
> working in Python or a shell, I spend the first hour scouring the web to
> find some way of using Emacs with those processes in the way that ESS works
> with R.  I haven't found anything yet, although python-mode is getting a
> little closer.
>
> For the way that I write code, ESS is the gold standard for interactive
> programming, and I have tried a lot of different (free) IDE's over the
> years.  It would be fantastic if that part of ESS could be made its own
> package.
>
> Thanks for all the great work you all do,
>
> Best,
> Matt
>
>
> On Thu, Oct 10, 2013 at 7:56 PM, Kasper Daniel Hansen <
> kasperdanielhansen at gmail.com> wrote:
>
>> As Andreas said, I have never encountered anything like ESS support for
>> interacting with (multiple) processes from (multiple) file(s).  But as
>> Rodney says, I am not an expert on all things emacs.  In theory, it is
>> pretty simple: send text from one buffer to another, but we just have a lot
>> of experience with this in ESS.
>>
>> Besides R, I could easily see use for this in
>>   bash scripting
>>   matlab
>>   python (but I am not really familiar with python in Emacs)
>>   julia
>>
>> As Andreas says, I am not the one to do the work, but I believe such a mode
>> would be a major asset to Emacs in general.
>>
>> All I am really doing is lending my strong support to this idea.
>>
>> Best,
>> Kasper
>>
>>
>> On Thu, Oct 10, 2013 at 5:25 PM, Vitalie Spinu <spinuvit at gmail.com> wrote:
>>
>> >
>> > More I think about it more I am inclined towards adding it. The reason
>> > is data pre-processing which is often done with one-line tools like sed
>> > and awk. New pyed piper is coming in force http://code.google.com/p/pyp/
>> .
>> >
>> > I am still not sure I want to see it as part of ESS. In a long run
>> > isolating our ess-inf into a separate package is a very good idea. Such
>> > a package should come with a lot of load like support for eldoc,
>> > documentation and auto-completion. So it's quite a lot of ESS to be
>> > factored out and it is not easy without rewriting a lot of it.
>> >
>> >
>> >    Vitalie
>> >
>> >
>> >
>> >  >>> Rodney Sparapani on Thu, 10 Oct 2013 15:45:09 -0500 wrote:
>> >
>> >  > On 10/10/2013 03:07 PM, Andreas Leha wrote:
>> >  >> As I wrote the feature request, let me comment a bit.
>> >  >>
>> >  >> I completely understand your point.  And since (unfortunately) it
>> won't
>> >  >> be me who implements shell support in ess, I of course accept your
>> >  >> point.
>> >  >>
>> >  >> That said, see my inline comments below.
>> >  >>
>> >
>> >  > Hi Andreas:
>> >
>> >  > Well, I enjoy arguing more than actually working so see below...
>> >
>> >  >> Rodney Sparapani<rsparapa at mcw.edu>  writes:
>> >  >>> >Well then...  Although I am an ESS developer, this is only my
>> >  >>> >personal opinion.  I too find myself writing Bourne shell scripts
>> >  >>> >(for the last 20 years now ;o)  However, I feel that the emacs
>> >  >>> >community is well aware of the Bourne shell and its imitators.
>> >  >> Can you point to any emacs shell support, that comes close to what
>> ess
>> >  >> can do for real (?) statistical languages in terms of connecting the
>> >  >> script with a process?
>> >  >>
>> >
>> >  > No.  But, that doesn't mean it doesn't exist.  I can't keep up with
>> >  > all of the different emacs modes that are floating around cyberspace.
>> >
>> >  >>> >
>> >  >>> >IMHO the ESS developers want to fill the niche that
>> >  >>> >statisticians and statistical programmers/analysts find
>> >  >>> >in emacs.  There are a lot of things that would be nice to
>> >  >>> >have that we are not going to be able to add due to time,
>> >  >>> >warm bodies, climate change, etc.
>> >  >> As also others have argued, shell scripting can be seen as being part
>> > of
>> >  >> the full statistical workflow.  I assume, you'd not want to do your
>> > real
>> >  >> (?) statistical scripting without ess' support for sending code from
>> >  >> your script to the process.  Why would you not want similar support
>> for
>> >  >> the part of the data analysis, that is done in the shell?
>> >  >> So, the step to shell support, for me, is a natural one, the step to
>> >  >> climate change is not.
>> >  >>
>> >
>> >  > My point is that as statisticians, we pick our battles.  There is a
>> >  > reason that SAS and R are prevalent in statistics while other
>> >  > interactive languages like Perl and Python are not.  I do agree that
>> >  > Bourne shell scripting is worth learning; but then I am a Linux/UNIX
>> >  > bigot who has seen the error of my OS/2 ways; lots of Windows
>> >  > folks would disagree.
>> >
>> >  >>> >
>> >  >>> >When we get to that point (and I feel it is a ways off yet),
>> >  >>> >then we could re-consider.  Normally, at this point, I would
>> >  >>> >say glibly "patches welcome".  However, I don't think they
>> >  >>> >really are right now.  Whenever we accept a patch, then we
>> >  >>> >end up maintaining it (except in the rare exception when we
>> >  >>> >can convince the author to stick around).  So, I personally
>> >  >>> >am in no hurry; I would postpone this until the rewrite is
>> >  >>> >complete when we can consider what languages to add then.
>> >  >> This already sounds as if such a rewrite will definitely happen --
>> even
>> >  >> if ways off.  That is nice.
>> >  >>
>> >
>> >  > Yes, we have been talking about it, but talk is cheap ;o)
>> >
>> >  >>> >
>> >  >>> >I have my doubts whether the Bourne shell will be able to compete
>> >  >>> >for attention with julia, polymode, SLIME[R] and/or whatever new
>> >  >>> >fangled flavor of the month the kids come up with.  But that's
>> >  >>> >just the opinion of one eternal pessimist.
>> >  >> Given that you have done shell scripts for 20 years, you probably
>> > agree,
>> >  >> that shell scripting is not one of the 'new fangled flavor[s] of the
>> >  >> month'.
>> >
>> >  > I do.  But, I meant it in the mindshare sense.  IMHO there will always
>> >  > be something that we would rather add than shell scripting whether
>> >  > right or wrong.  Polymode and SLIME[R] are just too sexy to resist
>> >  > while it's easy to poo poo stodgy old shell scripts.
>> >
>> > ______________________________________________
>> > ESS-help at r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/ess-help
>> >
>>
>>         [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> ESS-help at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/ess-help
>>