[ESS] disabling C-c h bound to ess-handy-commands

Vitalie Spinu spinuvit at gmail.com
Mon Oct 8 10:48:41 CEST 2012


  >> "Richard M. Heiberger" <rmh at temple.edu>
  >> on Sun, 7 Oct 2012 23:27:57 -0400 wrote:

  > Vitalie,

  > Let me rephrase this discussion as it has migrated to make sure I
  > understand it. The proposal is to remove C-c C-n and C-c C-r, the
  > workhorse keystrokes I have been using forever and which my fingers
  > know, and replace them with C-c C-c which is relatively new (and
  > which I have started using) and with C-RET which is totally new in
  > 12.09. C-c C-c has the interesting side-effect of encouraging
  > writing code with blank lines between sections so the automatic
  > detection of paragraphs will find what I want.

  > If my understanding of the issue is right, then I have to withhold
  > my opinion until I spend time actually using C-RET

Indeed this is the issue, what we have very versatile C-c C-c, C-M-x and
C-RET and our key-map is full of redundant ess-eval-*. We also had C-c
C-e bound to eval-map till roxy-mode hijacked it :)

Another issue is that we have very particular commands
(ess-dump-object-into-edit-buffer, ess-execute-in-tb) taking one full
handy key. It's much better to set those keys to full maps (like
ess-doc-map, ess-dev-map etc).

I don't have a strong opinion on C-c C-n, except that it might be bound
to ess-next-code-line (as it is done in octave for example). The problem
is that then we would need to rebind C-c C-p for consistency, but C-c
C-p as we have it now is still pretty useful in some limited cases.

    Vitalie


  > On Sun, Oct 7, 2012 at 10:27 PM, Ali Tofigh <alix.tofigh at gmail.com> wrote:

  >> On Sun, Oct 7, 2012 at 4:32 PM, Vitalie Spinu <spinuvit at gmail.com> wrote:
  >> > I propose to redefine/remove some less used key. For instance
  >> >
  >> > C-c C-d         ess-dump-object-into-edit-buffer
  >> >
  >> >   Would be good to have this for documentation (index, apropos etc) like
  >> >   slime does. And put ess-dump-object-into-edit-buffer on C-c C-e or
  >> >   something else.
  >> >
  >> > C-c C-f         ess-eval-function
  >> >   This one is redundant with C-c C-c and C-M-x, may be remove altogether
  >> >   and put something useful on it.
  >> >
  >> > C-c C-k         ess-force-buffer-current
  >> >   Is this one equivalent to C-c C-s?
  >> >
  >> > C-c C-n         ess-eval-line-and-step
  >> >   We have C-RET for this. C-c C-n is too lengthy for such a task. Can be
  >> >   removed.
  >> >
  >> > C-c C-r         ess-eval-region
  >> >   If transient-mark is active. This one is redundant with C-c C-c,
  >> >   C-M-x, C-RET. Roxygen would be good on it.
  >> >
  >> > C-c C-t         ess-execute-in-tb
  >> >   Who is using this one? Would be good to have it for dev-map.
  >> >
  >> > C-c C-y         ess-switch-to-ESS
  >> >   Who is using this one? C-c C-z should be pretty enough.
  >> 
  >> I actually didn't know about the versatility of C-c C-c until now that
  >> you mentioned it, so I have become used to using many of the shortcuts
  >> in your list. But I can easily relearn to use only C-c C-c and C-c
  >> RET, which seem to be the only ones I would need. You didn't mention
  >> C-c C-p which evaluates a paragraph. But I actually think that C-c C-p
  >> should be kept, becuase I often wind up evaluation paragraphs inside
  >> functions when debugging. So in summary, I would personally agree that
  >> all the shortcuts you mentioned could be replaced, except for C-c C-p,
  >> which you actually didn't mention. :-)
  >> 
  >> /Ali
  >> 
  >> ______________________________________________
  >> ESS-help at r-project.org mailing list
  >> https://stat.ethz.ch/mailman/listinfo/ess-help>



More information about the ESS-help mailing list