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@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@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@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@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/ess-help
> >
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew Landis, Ph.D.
Research Scientist
ISciences, LLC
61 Main St., Suite 200
Burlington VT 05401

802-864-2999
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	[[alternative HTML version deleted]]

