[RkWard-devel] Send pre-defined block to R console

[Thomas Friedrichsmeier]

Hi Dan,

taking this to the mailing list, intead, as it's much more comfortable to 
handle this through my inbox, than the web-interface to the tracker, hope 
that's ok. I don't know, whether you're subscribed to the list. If so, give 
me a note, so I can drop the CC in subsequent mails.

Dan wrote (in the tracker: 
https://sourceforge.net/tracker/?func=detail&atid=459010&aid=1672562&group_id=50231):
>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:

Minor point: Symbols can the overlaid in the icon border, so it may make sense 
to instead use only a small ">" at the top, and a small "<" a the bottom. The 
one-line one would then simply be both combined, and not need any extra 
symbol.

[...]
>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 could find a good way to represent this, that would be nice, I think. In 
your original example (script file with several function definitions, and 
then in a different part of the script file function calls), this would allow 
you to swiftly switch back and forth between developing / testing function A, 
and working on function B. Those would be two separate discontinous blocks.

To throw in a thought (not convinced it's the best solution, yet, but an 
idea):
- Use your proposed "<" and ">" symbols.
- The default behavior of the "Run block" action will be to run the continuous 
block between the nearest ">" above and "<" below the cursor (if defined).
- Introduce additional symbols "A", "B", "C", and "D" (assuming "nobody will 
ever need more than for regions of code")
- These can be placed anywhere between "<" and ">".
- If the current region has an "A" symbol somewhere inside it, the "Run block" 
behavior will be different. In this case, the editor will investigate all 
defined regions from start to end. It will concatenate all regions 
marked "A", and run those.

Advantages:
- Pretty flexible
- Defining and using several distinct regions which are each continuous is 
simple
- Several continous and / or discontinous regions can be defined

Disadvantages:
- Using dis-continuous regions is a bit more work, and not exactly 
self-explanatory

Thoughts on this? Other suggestions?

General considerations:
Sticking with the katepart icon border is probably a good idea, even if it not 
really designed to support this sort of advanced region markup. The major pro 
is that it will take care of adjusting the regions as needed, when lines are 
added/removed. I imagine this could be fairly tricky to get right, if using 
any other solution.

>If we agree that this feature is worth, and we also agree on its specs, I
>could try to implement it :)

I think we do agree the feature is worth having. Let's think about the specs 
for another short while, to see if we can come up with a real nice solution. 
After that, if you'd like to give the implementation a shot, that would be 
very much appreciated!

Note: I'm away from email in a few minutes, so I won't reply personally, 
probably until Sunday. But maybe other people on this list (more than are 
subscribed to the tracker notifications) have some nice ideas on this as 
well, so go ahead and discuss.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070302/2f17bc96/attachment.sig>