[rkward-devel] Better keybindings for "Run"

[Milan Bouchet-Valat]

Le mardi 17 janvier 2012 à 17:14 +0100, Thomas Friedrichsmeier a écrit :
> well, Ctrl+R makes a lot of sense in the context of R GUIs. In our case it is 
> taken by "Replace", already, which also makes a lot of sense, in general. 
> There are two main problems with changing that. First, "Replace" is provided 
> by the embedded kate part. It is not impossible to change the associated 
> shortcut, but it's not really an intended usage of embedded KDE parts, either. 
> Changing this keyboard shortcut would involve using a hack which is likely to 
> break sooner or later, without prior warning. Second, "Replace" is a 
> comparatively important task. Changing it's shortcut (which is a default 
> shortcut, shared across KDE applications) to execute some R code, instead, 
> definitely has potential for causing some unpleasant surprises.
Indeed, I could have figured it out myself. ;-)

> So I think, Ctrl+R is a no-go. Which doesn't mean to say that the current 
> shortcuts are the only / best option. But finding good shortcut combinations 
> (esp. for a series of similar actions), which do not cause conflicts, is 
> notoriously difficult.
I've had a look at a few IDEs for R. RStudio seems to have the same
scenario as RKWard, and to have a reasonable solution:
Ctrl+Enter to run current line/selection
Ctrl+Shift+Enter to run current document
Ctrl+Shift+B to run from document beginning to current line
Ctrl+Shift+E to run from current line to document end
Ctrl+Shift+F to run the current function definition
Ctrl+Shift+P to re-run previous region

(BTW, the four latter shortcuts could be useful, I never thought about
them. But that's of course a separate subject.)

> I think that's a good idea, in principle. Not sure, wether such a "combined" 
> action would replace the others, entirely. Also, I tend to think that it may 
> be more natural to combine the "run selection" behavior with "run file", in 
> case no selection exists. Many existing actions already use similar semantics 
> (also in other applications). In many cases (for simple top-level statements), 
> "run line" can be used as a sort of step-by-step execution, and I think it 
> will be useful to keep this separate.
I really think merging selection/line is the most natural solution.
RStudio does this (I promise, I didn't know it did before suggesting
this change :-), but also SciViews-K (Ctrl+Shift+R). One reason can be
that running the whole file can have bad consequences, so it shouldn't
be possible to run it by mistake, e.g. if you thought you had selected
something and you actually don't. And I think it's really a specific
operation, because it doesn't depend on the place the cursor is in the
file, contrary to the two others.

> How do others feel about this? Which actions could be merged this way? Should 
> the single actions remain in addition to that? Should they continue to have a 
> default keyboard shortcut?
Now, if people think that's wrong, I won't threaten of stopping to use
RKWard or anything. ;-)

> In fact, it would be possible to keep a bit of both in the toolbar: It is 
> possible to create a tool-button with a dropdown, similar to the "back" 
> buttons on many browsers. Simply clicking the button would execute the 
> "combined" action, depending on whether or not there is a selection. Clicking 
> a small arrow at the side would show the current specific actions in a 
> dropdown.
Yeah, but I'm not sure that's really worth it. It's easier to select or
deselect some code and run the combined action, than to use the
drop-down list just to avoid selecting/deselecting the right thing.

> Could it be you are using the "Text alongside icons" placement option (RMB 
> click on the toolbar(s))? "Text below icons" can save a lot of horizontal 
> space. That is also available as a global KDE setting, so if you run into 
> similar problems in other KDE applications, consider checking your system 
> settings.
Yeah, I am. But actually I prefer saving vertical space, which is
expensive on 16:9 screens. I don't personally need the buttons that
don't fit on the toolbar, so I don't really care, but I think it should
be a goal to fix this kind of thing, especially because it seems to be
possible easily.


Let's see what others say...