2 things I wish ESS would do

[Paul Johnson-11]

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

--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[Richard M. Heiberger]

Paul,

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.


This is available.  Use M-x ess-transcript-clean-region and
ess-transcript-clean-buffer
to remove all lines from the transcript buffer that are not input lines.
These functions are designed for the ESS transcript buffer.  They work, but
not well, in
the *R* buffer.   Therefore your steps would be to highlight and copy an
output region to a blob.rt buffer, use C-x C-q to make it writable, then use
ess-transcript-clean-buffer to isolate the input lines.  Edit out the
redundancies
and false starts.  Save the resulting lines in your original blob.R or in
another myfile.R.


On the option to save C-c C-n lines as part of R history, I want that too.
My motivation includes yours.  In addition, I want the option to make
the *R* buffer to behave the same as the S-Plus GUI on Windows.
The GUI is a parallel process to emacs, not
an inferior process of emacs as the *R* buffer is.  Therefore the GUI does
not
distinguish between lines that are sent over with C-c C-n and lines that are
manually typed.  I looked at the code a few years ago and decided the
relevant
code was buried deeper than I wanted to find at that time.  If you can find
the
location that needs adjusting, I will be happy to install the adjustment.

Rich

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[Stephen Eglen]

Dear Paul,
thanks for your comments.  Here are my views, perhaps others in
ess-core will chip in with theirs:

 > 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.

If there is an easy way of stashing commands into Emacs' history, then
I see no reason why it shouldn't be done, and made an option (default
off).  I'm not sure if anyone has investigated it.  And presumably it
gets complicated, what if I eval a whole region of several lines at
once -- should they all go in as one history item(if they can),  or
broken up into lines?  Or should this be available only for the ESS
commands that send one line at a time to an *R* buffer?

 > 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.

The transcript editing code might be useful here.  e.g. given some
region of *R* output like

> x <- rnorm(2)
> x + 3
[1] 3.091824 4.764668
> x - 1
[1] -0.9081763  0.7646682
>
if I copy & paste that into a buffer called "foo.Rt" and then make the
buffer writeable (C-x C-q) and then do C-c C-w
(ess-transcript-clean-region) on the whole buffer, I get:

x <- rnorm(2)
x + 3
x - 1

It should be straightforward to write a defun that takes a marked
region in a *R* buffer, copies it to some temp buffer (e.g. called foo.Rt)
and then runs ess-transcript-clean-region.

However, where would you then want the contents of foo.Rt copied?  In
your case, you would say blob.R, but what if the *R* process is being
used by several .R files [at least I often associate one *R* process
with several buffers].  Some heuristic could be used, e.g. stick it at
point in the most recent .R buffer associated with that process.

would that work for you?

Stephen

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[Charles C. Berry]

Paul,

I cannot grant either wish, but I can mention a couple of workarounds.

For 1) using the 'occur' command is a useful (and sometimes
better) substitute:

  M-x occur RET ^> RET

will create an *Occur* buffer with all the lines from your current buffer
that start with '>'. So if you start from an *R* buffer, you will get all
the first lines of all commands. If you click on any line in the *Occur*
buffer you get put in the *R* buffer with point at the command. You can
then type RET to execute it or C-c RET to get a copy of that command
copied to the bottom - ready to edit and execute.

You can bind the keystrokes above to a macro so you can hit one key to get
all the commands in an *Occur* buffer. And you can use '^[>+][ ]' as the
regexpr to get all the continuation lines, too, if you want.

For 2), there was a macro posted to this or a similar list many years back
(apologies to the author whom I've lost track of and thanks for a terrific
hint). It is

  (fset 'push-line-other-window
        "\C-@\C-e\M-w\C-n\C-a\C-xo\M->\C-y\C-m\C-xo")

I bind this to a key, and when I push that key it copies the rest of the
line after point to the end of the buffer in the other window, then moves
point to the next line of the current window to the position after the
prompt. If I am working in *R* and want to copy a command to myR.R which
is in the other window, I position point before the command and hit the
key. To copy multiple lines, I just keep hitting the key. If I want to
copy to the middle of myR.R, I use C-x n n to narrow to the region where I
want the new commands to go. It also works nicely to move and execute
commands (like debugging statements) I've commented out in myR.r back to
*R* for execution.


HTH,

Chuck


On Wed, 30 Apr 2008, Paul Johnson 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
>
> --
> Paul E. Johnson
> Professor, Political Science
> 1541 Lilac Lane, Room 504
> University of Kansas
>
> ______________________________________________
> ESS-help@... mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help
>

Charles C. Berry                            [phone]
                                             Dept of Family/Preventive Medicine
E mailto:cberry@...            UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[Dr. Alun Pope]

Agree with all your sentiments, Paul, especially the reasons for using
Emacs and ESS and R and Latex (and Rweave) and thanks for the helpful
work-arounds etc from the other guys.  

Alun

Alun Pope
Research Manager
Rismark International




 

-----Original Message-----
From: ess-help-bounces@...
[mailto:ess-help-bounces@...] On Behalf Of Paul Johnson
Sent: Thursday, 1 May 2008 1:57 AM
To: ess-help
Subject: [ESS] 2 things I wish ESS would do

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

--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[Munawar Cheema]

I would just like to say that the two requests that Paul Johnson makes in
the OP would be useful to me too.
The work around suggestions were very helpful and I think I can use those to
get things working for me and I learnt a few new things from them.

Regards
Munawar Cheema
Manchester Business School

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[A.J. Rossini]

I agree fully.  Paul has made 2 nice requests -- the second I think is
solvable, the first ought to be solvable by stashing submit commands
to comint history (or by interweaving a set of history caches).

But there is a good bit of consideration to be done, as Stephen notes.

Patches are of course welcome; the internal guts are tricky to work out.

On Thu, May 1, 2008 at 6:31 PM, Munawar Cheema <mcheema@...> wrote:

> I would just like to say that the two requests that Paul Johnson makes in
>  the OP would be useful to me too.
>  The work around suggestions were very helpful and I think I can use those to
>  get things working for me and I learnt a few new things from them.
>
>  Regards
>  Munawar Cheema
>  Manchester Business School
>
>
>
>  ______________________________________________
>  ESS-help@... mailing list
>  https://stat.ethz.ch/mailman/listinfo/ess-help
>

--
best,
-tony

blindglobe@...
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee: Do stupid things faster with more energy!

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[David Whiting]

Dear Paul and others,


On Wed, Apr 30, 2008 at 06:31:56PM +0100, Stephen Eglen wrote:
>
> Dear Paul,

[...]

>  > 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.


I have found myself often wanting to do this as well, and needed to
again today. So, based on Stephen's outline, I have hacked some code
together. See below.

> The transcript editing code might be useful here.  e.g. given some
> region of *R* output like
>
> > x <- rnorm(2)
> > x + 3
> [1] 3.091824 4.764668
> > x - 1
> [1] -0.9081763  0.7646682
> >
> if I copy & paste that into a buffer called "foo.Rt" and then make the
> buffer writeable (C-x C-q) and then do C-c C-w
> (ess-transcript-clean-region) on the whole buffer, I get:
>
> x <- rnorm(2)
> x + 3
> x - 1
>
> It should be straightforward to write a defun that takes a marked
> region in a *R* buffer, copies it to some temp buffer (e.g. called foo.Rt)
> and then runs ess-transcript-clean-region.
>
> However, where would you then want the contents of foo.Rt copied?  In
> your case, you would say blob.R, but what if the *R* process is being
> used by several .R files [at least I often associate one *R* process
> with several buffers].  Some heuristic could be used, e.g. stick it at
> point in the most recent .R buffer associated with that process.
>
> would that work for you?
>
> Stephen

The following attempts to implement part of Stephen's idea. It does
not attempt to figure out where to place the code, it just gets as far
as removing the output and copying the remaining code. I couldn't
figure out how to tell emacs not to ask if I want to save foo.Rt. Now
I'll hand over to someone who knows what they are doing :)


(defun ess-snarf-commands ()
   "Extract some commands from the R prompt and remove the output."
  (interactive)
  (copy-region-as-kill-nomark (mark) (point))
  (find-file "foo.Rt")
  (switch-to-buffer "foo.Rt")
  (vc-toggle-read-only)
  (yank)
  (ess-transcript-clean-buffer)
  (beginning-of-buffer-nomark)
  (end-of-buffer-mark)
  (copy-region-as-kill-nomark (mark) (point))
  (kill-buffer "foo.Rt"))



David


--
David Whiting, Ph.D.
Advancing Research in Chronic Disease Epidemiology (ARCHEPI) programme
Institute of Health and Society, The Medical School,
Newcastle University, Framlington Place, Newcastle upon Tyne, NE2 4HH.
Tel: [phone];  Extn: 7375; Fax: [phone].
http://research.ncl.ac.uk/archepi
www.ncl.ac.uk/ihs

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[Tyler Smith]

David Whiting <david.whiting@...> writes:

> Dear Paul and others,
>
>
> On Wed, Apr 30, 2008 at 06:31:56PM +0100, Stephen Eglen 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.
>
>
> I have found myself often wanting to do this as well, and needed to
> again today. So, based on Stephen's outline, I have hacked some code
> together.
>

It seems to me that most of the necessary functions are already present
in ESS, just not available from ESS[S] mode. If inferior-ess-prompt were
defined for this mode, and the functions for transcript mode loaded,
there's not much left to do.

After manually defining inferior-ess-prompt in the .R buffer, and
loading transcript mode (doesn't seem to matter which buffer it gets
loaded for), the following works:

copy commands and output in the process buffer with M-h and M-w
switch to the desired .R buffer
yank the selection
select it and invoke ess-transcript-clean region

Is there a good reason to keep the ess-transcript functions and
inferior-ess-prompt hidden from ESS[S] mode? Appropriate helper
functions would be easy to cook up if the these items were available. I
imagine a single command to collect the current region in the process
buffer, prompt for the destination buffer, possibly with a default, and
then paste and clean the kill-ring at point in the destination buffer.

Cheers,

Tyler

--
Power corrupts. PowerPoint corrupts absolutely.
                                       --Edward Tufte

http://www.wired.com/wired/archive/11.09/ppt2.html

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[A.J. Rossini]

(only answering one of Tyler's questions)

On 5/6/08, tyler <tyler.smith@...> wrote:
> David Whiting <david.whiting@...> writes:

> Is there a good reason to keep the ess-transcript functions and
> inferior-ess-prompt hidden from ESS[S] mode? Appropriate helper
> functions would be easy to cook up if the these items were available. I
> imagine a single command to collect the current region in the process
> buffer, prompt for the destination buffer, possibly with a default, and
> then paste and clean the kill-ring at point in the destination buffer.

To answer your question:  there are reasons, "goodness" being in the
eye of the beholder.

Originally (1994-1996 era), we (at least I) wanted to ensure
workflow/process restrictions on what you could do in a particular
mode, to simplify training.

That has proven to be rather old fashioned and restrictive, as new
workflows/processes for doing statistical activities are
created/desired, as more and more people use this tool.

So refactoring those functions into a general support location would
be a great idea, for reuse by the various modes.

best,
-tony

blindglobe@...
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee:  Do stupid things faster with more energy!

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[Tyler Smith]

"A.J. Rossini" <blindglobe@...> writes:

> On 5/6/08, tyler <tyler.smith@...> wrote:
>
>> Is there a good reason to keep the ess-transcript functions and
>> inferior-ess-prompt hidden from ESS[S] mode? Appropriate helper
>> functions would be easy to cook up if the these items were available. I
>> imagine a single command to collect the current region in the process
>> buffer, prompt for the destination buffer, possibly with a default, and
>> then paste and clean the kill-ring at point in the destination buffer.
>
>
> ... refactoring those functions into a general support location would
> be a great idea, for reuse by the various modes.
>
> best,
> -tony
>

Ok, so how about something like this:

ess-cust.el, ca. line 1269, to make inferior-ess-prompt global:
 
;; Tyler commented this out:
;;(make-variable-buffer-local 'inferior-ess-prompt)

ess-trns.el, ca. line 35, to allow for require-ing a named feature:

(provide 'ess-trns) ;;Tyler added for require from ess-mode

and ess-mode.el, ca. line 36, to load ess-trns for ess-mode:

(require 'ess-trns); Tyler added to allow for easy cleaning of code
                   ; copied from the process buffer


With that done, and taking advantage of iswitchb, I have the following
new functions for ess-inf.el:

;; transfer commands to script buffer:
(defun ess-extract-commands-and-go (beg end)
  "Paste the commands in the region to a script buffer and go there."
  (interactive "r")
  (kill-ring-save beg end)
  (iswitchb-buffer)
  (setf start (point))
  (yank)
  (setf end (point))
  (ess-transcript-clean-region start end nil))

(defun ess-extract-commands (beg end)
  "Paste the commands in the region to a script buffer."
  (interactive "r")
  (kill-ring-save beg end)
  (set-buffer (iswitchb-read-buffer "select a buffer:"))
  (setf start (point))
  (yank)
  (setf end (point))
  (ess-transcript-clean-region start end nil))

If that looks sensible it could be further tweaked to provide sensible
defaults for the buffer selection step, which may or may not use the
iswitchb functions. In particular, we'd have to insure that the
destination buffer was in ESS[S] mode. Ideas?

Cheers,

Tyler

--
The purpose of models is not to fit the data but to sharpen the questions.
                                       --Samuel Karlin

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[A.J. Rossini]

The first mod is dangerous -- some of us (well, I can think of only
one person, but that's me) still run multiple things out of one emacs
session -- R, S4, S-PLUS, etc... and hence the first change (going
from buffer-local to global var) kills me.

This is part of what I've been trying to find time to do for about 5-6
years now, rewrite the internals to be sane.

A bit busy today, but will take a look at it soon (famous last words,
I said the same thing back then, as well).

If you can use git for version control, we can work out of the ESS
repo on repo.or.cz (I need to update it) and can then hash out the
changes safely.

On Mon, May 12, 2008 at 11:40 AM, tyler <tyler.smith@...> wrote:

> "A.J. Rossini" <blindglobe@...> writes:
>
>  > On 5/6/08, tyler <tyler.smith@...> wrote:
>  >
>
> >> Is there a good reason to keep the ess-transcript functions and
>  >> inferior-ess-prompt hidden from ESS[S] mode? Appropriate helper
>  >> functions would be easy to cook up if the these items were available. I
>  >> imagine a single command to collect the current region in the process
>  >> buffer, prompt for the destination buffer, possibly with a default, and
>  >> then paste and clean the kill-ring at point in the destination buffer.
>  >
>  >
>  > ... refactoring those functions into a general support location would
>
> > be a great idea, for reuse by the various modes.
>  >
>  > best,
>  > -tony
>  >
>
>  Ok, so how about something like this:
>
>  ess-cust.el, ca. line 1269, to make inferior-ess-prompt global:
>
>  ;; Tyler commented this out:
>  ;;(make-variable-buffer-local 'inferior-ess-prompt)
>
>  ess-trns.el, ca. line 35, to allow for require-ing a named feature:
>
>  (provide 'ess-trns) ;;Tyler added for require from ess-mode
>
>  and ess-mode.el, ca. line 36, to load ess-trns for ess-mode:
>
>  (require 'ess-trns); Tyler added to allow for easy cleaning of code
>                    ; copied from the process buffer
>
>
>  With that done, and taking advantage of iswitchb, I have the following
>  new functions for ess-inf.el:
>
>  ;; transfer commands to script buffer:
>  (defun ess-extract-commands-and-go (beg end)
>   "Paste the commands in the region to a script buffer and go there."
>   (interactive "r")
>   (kill-ring-save beg end)
>   (iswitchb-buffer)
>   (setf start (point))
>   (yank)
>   (setf end (point))
>   (ess-transcript-clean-region start end nil))
>
>  (defun ess-extract-commands (beg end)
>   "Paste the commands in the region to a script buffer."
>   (interactive "r")
>   (kill-ring-save beg end)
>   (set-buffer (iswitchb-read-buffer "select a buffer:"))
>   (setf start (point))
>   (yank)
>   (setf end (point))
>   (ess-transcript-clean-region start end nil))
>
>  If that looks sensible it could be further tweaked to provide sensible
>  defaults for the buffer selection step, which may or may not use the
>  iswitchb functions. In particular, we'd have to insure that the
>  destination buffer was in ESS[S] mode. Ideas?
>
>  Cheers,
>
>  Tyler
>
>  --
>  The purpose of models is not to fit the data but to sharpen the questions.
>                                        --Samuel Karlin
>
>
>
>  ______________________________________________
>  ESS-help@... mailing list
>  https://stat.ethz.ch/mailman/listinfo/ess-help
>

--
best,
-tony

blindglobe@...
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee: Do stupid things faster with more energy!

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[Spinu Vitalie]

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@...>  
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
>

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[Stephen Eglen-2]

Vitalie Spinu <vitosmail@...> wrote:

> 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?

Yes, the history of commands typed into an *R* buffer can be found in
the variable comint-input-ring  and you can even get a separate window
showing its contents to date using M-x comint-dynamic-list-input-ring
(C-c M-l)

but as you type new commands, that input history is not automatically
updated (which is what you want I think).

So I think the answer for now is that with a bit of lisp'ing, you could
get something working (e.g. a hook to refresh the history after each new
command, and perhaps put the commands in their own dedicated window).
Done in the right way, it need not even be specific to ESS, and so other
modes could also benefit.  Its probably a few hours work, but I don't
have that time spare right now...

Stephen

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help