[ESS] New behavior of C-c C-z (Re: Feedback on 12.04)

Sat Oct 20 12:04:16 CEST 2012

  >> Martin Maechler <maechler at stat.math.ethz.ch>
  >> on Sat, 20 Oct 2012 09:19:01 +0200 wrote:

[...]

  > I'm sure I'm not 100% uptodate on this topic, *but* I know that we
  > had introduced the "jump to END OF BUFFER of iESS" (typically *R*)
  > very much on purpose because ESS users wanted it... I think I have
  > used this quite often, because indeed I most of the time wanted to
  > jump to EOB in *R* when coming from the script file. It could be
  > that this is much less important now that (I think) the iESS
  > (comint) buffer is scrolled automatically and point typically is at
  > EOB in that buffer .... Is this the reason why you (and others)
  > think that "jump to EOB" is no longer much needed ?

Yes,  precisely. If the point is at eob (and it is usually there) then
all the inserted input/output stays before the point. In case your point
is not after the process mark comint doesn't move it on output (unless
you have some hooks activated). And this is a good thing.

So the motivation is as follows. In 99.9% of the cases the point is
already at the EOB and -goto-end-of-ESS is redundant. The issue is what
happens in the remaining 0.1%. In most likely scenario you have moved
your point up in the buffer for a reason, and would like to return to
that point. Now because you are so used to C-c C-z shortcuts, even if
you know about C-c C-y, you are likely to automatically press C-c
C-z. In another scenario, when you really need to go to EOB, you can do
C-c C-z M->, not a big deal.

So in my opinion, this behavior is almost uniformly better. Also because
it's less of a burden for the user to remember two almost redundant
keys.

Still, it should be tried. May be I am grossly overestimating this 99.9% ;)

    Vitalie

  >> If you have suggestions or objections better air them now, otherwise
  >> this will end up in the next patch release.
  >> 
  >> Vitalie
  >> 
  >> >> Vitalie Spinu <spinuvit at gmail.com>
  >> >> on Mon, 09 Apr 2012 09:58:06 +0200 wrote:
  >> 
  >> >>>>> Frede Aakmann Tøgersen <frtog at vestas.com>
  >> >>>>> on Sun, 8 Apr 2012 10:56:32 +0200 wrote:
  >> 
  >> >> Hi Vitalie
  >> >> Actually I usually open an R script buffer first and then start R using M-x
  >> >> R. C-c C-z brings the cursor to the end of the IESS buffer. I would prefer to
  >> >> have C-c C-y to do the opposite, i.e. bring the cursor from the IESS buffer to
  >> >> the R script buffer. That is quite useful when you occasionally do a C-x 1 in
  >> >> the IESS buffer.
  >> 
  >> > All right, as nobody objected to changing the redundant meaning of C-c
  >> > C-y, this is what I propose:
  >> 
  >> > In script:
  >> 
  >> > C-c C-y: Show *R* buffer, but don't switch to it.
  >> > C-c C-z: Switch to the end of *R*
  >> 
  >> > In inferior (aka *R*):
  >> 
  >> > C-c C-z returns to the most recent R-buffer. Following invocations of
  >> > C-z (or just z) will jump to next buffer in order of recency. Shift-z
  >> > will get you back in the list of R buffers. For example if you press
  >> > "C-c C-z z z Z" you will get to 2nd most recent buffer. Same story with
  >> > C-c C-y for convenience.
  >> 
  >> > Currently C-c C-z and C-c C-/ are bound to the same thing in iESS,
  >> > ess-abort, which is also what C-x k will do. So not a big deal of a
  >> > loss.
  >> 
  >> > Vitalie.
  >> 
  >> >> If some people do not like the current default behaviour of '_' they can of course set the ess-smart-underscore variable.
  >> 
  >> >> Yours sincerely / Med venlig hilsen
  >> 
  >> >> Frede Aakmann Tøgersen
  >> >> Specialist, M.Sc., Ph.D.
  >> >> Siting & Modeling
  >> >> Plant Siting & Forecasting
  >> 
  >> >> Vestas Technology R&D
  >> >> T +45 9730 5135
  >> >> M +45 2547 6050
  >> >> frtog at vestas.com
  >> >> http://www.vestas.com>
  >> >> Company reg. name: Vestas Wind Systems A/S
  >> >> This e-mail is subject to our e-mail disclaimer statement.
  >> >> Please refer to www.vestas.com/legal/notice
  >> >> If you have received this e-mail in error please contact the sender.
  >> 
  >> >> -----Original Message-----
  >> >> From: ess-help-bounces at r-project.org [mailto:ess-help-bounces at r-project.org] On Behalf Of Vitalie Spinu
  >> >> Sent: 6. april 2012 13:56
  >> >> To: Marius Hofert
  >> >> Cc: ess-help at r-project.org
  >> >> Subject: Re: [ESS] Feedback on 12.04
  >> 
  >> >> Hi Marius,
  >> 
  >> >>>>> Marius Hofert <marius.hofert at math.ethz.ch>
  >> >>>>> on Fri, 6 Apr 2012 12:57:14 +0200 wrote:
  >> 
  >> >> 1) Starting a buffer with a new R process can be done via C-c C-y. By doing so,
  >> >> the point remains in the newly created buffer with the running R process. It
  >> >> would be great if the point could automatically jump back to foo.R on executing
  >> >> C-c C-y. I would find this useful, although a workaround is to start the R
  >> >> process with C-c C-n (if no active R process is there, a new one will be asked
  >> >> for and started -- doing it this way the point remains in foo.R).
  >> 
  >> >> This made me thinking. Currently we have C-c C-y which jump to iESS and
  >> >> C-c C-z which jump to iESS and move the point to the end of buffer. I
  >> >> find C-c C-y highly redundant, as I always want to jump to the end.
  >> 
  >> >> So I accept this as a relevant and valid point. Shall we make C-c C-y to
  >> >> show/start the inferior,  but stay in the current buffer? It will be a
  >> >> useful complement of C-c C-z this way.
  >> 
  >> >> 2) Assume again you are in the buffer containing the active R process. Issuing
  >> >> C-c C-q to close the buffer, the point (unfortunately) still remains in this
  >> >> buffer (instead of going back to foo.R). This is a bit annoying since,
  >> >> typically, one would like to jump to foo.R.
  >> 
  >> >> I have 10 foo[i].R in my emacs? Which shall ESS choose to jump back?
  >> 
  >> >> 3) Similarly for killing an R process. One changes the active buffer from foo.R
  >> >> to the R process buffer and then hits C-x k. The point then remains in the
  >> >> killed R process buffer. In most of the cases, one would like to continue the
  >> >> work in foo.R and so it would be great if a C-x k would throw the point back to
  >> >> foo.R instead of remaining in the buffer with the killed R process.
  >> 
  >> >> Same as above with an additional: If you kill the buffer, how come that
  >> >> your point is still in it? Killing the process buffer should kill the
  >> >> process and return to whatever buffer was active before, most likely
  >> >> foo.R in your case.
  >> 
  >> >> Vitalie.
  >> 
  >> >> ______________________________________________
  >> >> ESS-help at r-project.org mailing list
  >> >> https://stat.ethz.ch/mailman/listinfo/ess-help>
  >> ______________________________________________
  >> ESS-help at r-project.org mailing list
  >> https://stat.ethz.ch/mailman/listinfo/ess-help