[ESS] 2 things I wish ESS would do

[Vitalie Spinu]

Dear ESS Gurus,

Sorry for renewing an old thread but the posted question is related to  
mine:

Paul Johnson  wrote:
> 2. Can you make it easier to transfer commands that work from the *R*
> window back to the script file "blob.R" ?  Once we do hack our way to
> success in the *R* file, we want to get those commands back and save
> them.  At the current time, the only way I can find is to highlight
> the whole section of the *R* buffer, copy it over to "blob.R" and then
> delete all the lines that don't start with > and edit the rest.

A couple of work arounds have been proposed for the above request, mainly  
creating a temporary transcript buffer foo.Rt, coping the region and  
applying ess-transcript-clean-region.

Wouldn't it be easier if such a buffer exists from the very beginning of  
the session (say *history*) and all the input commands already cleaned of
> ,+ and indented appropriately being flushed into it automatically?

This "running history" is extremely handy as implemented in Matlab - at  
any time one can switch there and run/copy any range of lines.

For CLI in Linux the solution was proposed here  
http://wiki.r-project.org/rwiki/doku.php?id=tips:using-cli:history-window

To my understanding iESS command history is somewhere in the emacs memory.  
Is it possible somehow to flush it to an .R buffer and continuously update  
it?

Many thanks,
Vitalie.





On Wed, 30 Apr 2008 17:56:34 +0200, Paul Johnson <pauljohn32 at gmail.com>  
wrote:

> I have 2 requests/suggestion. These reflect my experience trying to
> teach students to use R with Emacs.
>
> 1. I asked for this before, some of you said it was unnecessary for
> you.  OK.  I still  wish the command history would interleave commands
> sent from the ESS script file and commands typed at the command
> prompt.  Since some of you don't want that, I don't want that imposed
> on everybody.  But can it please be an option?  In the past, some
> other users said they would like this, but we were shouted down by
> others who said "just go read your script file if you want to see what
> you did." But that really does not help.
>
> Here's why.  In "actual practice" this is how we use Emacs, ESS and R.
>  We open a file "blob.R" (or whatever) and we type whatever commands
> we want in there, and send them to the *R* session in a separate
> buffer.  Suppose we get errors in the *R* buffer.  We'd like to go
> there, recall the failed commands, and test changes.  After we fix
> errors, we are not sure what we want to do.  So we go over to the *R*
> buffer and start typing stuff in, testing commands, and such.  Maybe a
> student will make a mistake, accidentally destroy some data or such.
> It is very irritating that the command history you get with Control-up
> does not show all commands that have been executed.  It makes it
> harder to experiment, especially when students are trying to see "what
> works."  If we could Control-up to go backwards to find commands that
> came from the script file as well as from the *R* buffer, life would
> be so much happier.
>
> Of course, nobody who knows everything about R would need that
> function.  That's why I don't want it imposed on you.  I just want it
> for me & mine.
>
> 2. Can you make it easier to transfer commands that work from the *R*
> window back to the script file "blob.R" ?  Once we do hack our way to
> success in the *R* file, we want to get those commands back and save
> them.  At the current time, the only way I can find is to highlight
> the whole section of the *R* buffer, copy it over to "blob.R" and then
> delete all the lines that don't start with > and edit the rest.
>
> It would be really handy if there were some way to transfer the
> previous ten (or so)  commands from the *R* buffer back to the
> insertion point in blob.R.
>
> Or, how about click in a line in *R* and press a button to copy
> command back to script file?
>
> Again, I understand that people who know perfectly well what they are
> doing do not need features of this sort.  However, the people who are
> learning to use R need a little more consideration.
>
> I suppose you are thinking, "if your people don't know R, why are you
> bothering with Emacs-ESS?"  I'm endorsing Emacs because it is the only
> editor I know of that you can get for all platforms and I expect it
> will be maintained over the long term (because so many smart
> programmers use it). If we can teach students to use Emacs, they will
> have an editor that they can use if they want to learn to program in
> C, Java, LaTeX, or whatever else.  So, although Emacs is sometimes
> inconvenient in the short run, I expect it is beneficial in the long
> run.  Some of my Windows/Mac colleagues are endorsing an editor called
> "TINN-R" for students, or WinEdt.  I'm a conscientious objector on
> platform-limited editors...
>
> pj
>