[rkward-tracker] [ rkward-Feature Requests-1672562 ] Send pre-defined block to R console

Fri Nov 30 17:00:47 UTC 2007

Feature Requests item #1672562, was opened at 2007-03-02 17:55
Message generated for change (Comment added) made by tfry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=459010&aid=1672562&group_id=50231

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: RKWard user interface
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: ddediu (ddediu)
>Assigned to: Thomas Friedrichsmeier (tfry)
Summary: Send pre-defined block to R console

Initial Comment:
Hi,

I don't know if this suggestion makes any sense, but, as mostly a C/C++ developer used to this type of IDEs, I would prefer to have the possibility to send to the R console a predefined block (not necessarily contiguous) from a larger script file. 
Let me be more specific: I usually prefer to have large script files, split in functions and I mostly work by creating/debuging/modifying one or a couple of functions at a time, which I test by calling them with some params. Now, every time I modify such a function, I have to send its body to the R console and then its call, so that I test it. However, this involves selecting stuff from the script file every time, which gets rather tedious, especially when the function body grows across more than one screen.
Therefore, I think would be useful to have a way of defining in the editor window a sort of markers attached to specific lines (so that they move meaningfully when editing text) and a special "Send block to the R console" button which automatically sends to R only the defined block. Of course, this block does not have to be continuous...
I hope this is a good suggestion and, again, thanks for this amazing work,

Dan

----------------------------------------------------------------------

>Comment By: Thomas Friedrichsmeier (tfry)
Date: 2007-11-30 18:00

Message:
Logged In: YES 
user_id=300591
Originator: NO

All right, this is now implemented in the KDE 4 port (to be released as
0.5.0). It utilizes kate's arbitrary highlighting ranges to automatically
expand/contract the blocks as needed (character based!), and to indicate
them using a background color. Since this is not available in KDE 3, it's
near impossible to backport to the KDE 3 versions of rkward.

Six "blocks" are supported. More could easily be realized, technically,
but this would make it really hard to differentiate the blocks visually.
Blocks can be overlapping and / or nested, although overlaps cannot
currently be represented, visually (would need improvements in kate
rendering). Non-contiguous blocks are not supported for simplicity of code
and user interface, but then you can simply use two separate contiguous
regions, which should be good enough in most cases, I guess.

Shortcuts Alt+Shift+F1-F6 for running the blocks (yeah, I know, but it's
hard to find consequtive shortcut ranges which are not already assigned).

----------------------------------------------------------------------

Comment By: ddediu (ddediu)
Date: 2007-03-02 18:38

Message:
Logged In: YES 
user_id=1731761
Originator: YES

Hi, Thomas

I was actually thinking about having a single, let's call it, "run block",
but which could span across non-contiguous lines. More specifically, let's
say you have the following script file with numbered lines and you allow in
the left-hand number & folding margin of the editor to add three new
symbols, let's say "<" to mark the begining of a "run block segment", ">"
to mark the end of such a thing and "<>" to makr a one-line one. Then, your
file could look like:
  1
  2
< 3
  4
> 5
  6
<>7
  8
< 9
  10
  11
> 12
  13
which means that there is a single "run block" composed of 3 "run block
segments": lines 3-5, line 7 and lines 9-12. When the "run block" button
would be pressed, no matter where the cursor is in the editor window, the
entire block (i.e., the 3 segments) are send in sequence to the R console
(i.e., 3-5,7,9-12). They could represent, let's say, the body of a function
(3-5), its call (7) and a more complex call embedded in something else
(9-12). Does it make sense?
Now, I've never thought about having more than one such "run block", but
might be interesting (I cannot, for the moment, see the utility, but that's
my own limitation :( ).
If we agree that this feature is worth, and we also agree on its specs, I
could try to implement it :)

Thanks again, Dan

----------------------------------------------------------------------

Comment By: Thomas Friedrichsmeier (tfry)
Date: 2007-03-02 18:19

Message:
Logged In: YES 
user_id=300591
Originator: NO

Hi Dan,

thanks for your request.

This looks like a reasonable feature addition, although I can't quite
imagine how the UI to go with this would work. This particularily hinges on
the part about being able to select non-contiguous regions. The problem is
being able to specify which region to run. For contiguous regions, this
could be as simple, as having a shortcut to run whichever region the cursor
is in. For non-contiguous regions, I don't yet see a good way to allow
several different regions in the same file (i.e. have regions A.1, A.2, A.3
and B.1, B.2, where you'd typically want to either run all of A, or all of
B, but never all blocks at once). Do you have something on this in mind?

Roland Vollgraf proposed a similar idea a while ago (only continuous
regions, though), and started working on it. However, I have not heard back
from him since more than a month, now.

Again, it's probably a useful feature to have (whatever the details), but
I won't have the time to work on this anytime soon. If - as a C/C++
developer - you would like to look into this yourself, I'd be happy to
accept a patch. Main files to look into are
rkward/windows/rkcommandeditorwindow[part].[cpp|h]. You may also be
interested in this thread:
https://sourceforge.net/mailarchive/forum.php?thread_id=31467355&forum_id=12970
, which discusses Roland's proposal, and even has an almost complete patch
(missing some refinements, as discussed in the thread). Maybe you could
build on top of that.

Regards
Thomas

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=459010&aid=1672562&group_id=50231