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

[Thomas Friedrichsmeier]

On Monday 05 March 2007 11:03, Dan Dediu wrote:
> > One thing I'm a little concerned about is the number of different
> > actions we
> > will need for this. Currently it looks to me, like three different
> > actions
> > might be needed:
> > - Run current contiguous block (current==containing the cursor)
> > - Run current non-contiguous block (current==color/number/letter of the
> > block
> > containing the cursor, and all other blocks marked up in the same way)
> > - Run block... (with a dialog popping up, asking what to run)
>
> We must also add the actions needed to manage these, like:
> - define segment;
> - delete segment/block;
> - merge segment into block or blocks together;
> - cut a segment out of a block...

I don't think we need to offer all of this. For advanced editing of regions, 
one can use the icon border. For regular use, define region and delete region 
should be good enough. For define region, I'd suggest the following:
- This applies to the current selection (rounded to full lines). If nothing is 
selected, a dialog will come up saying "Sorry, nothing selected".
- If something is selected, a dialog will come up asking:
"Should this region/segment be part of a non-contiguous region?
 [X] No region
 [ ] Region A
 [ ] Region B
 [ ] Region C
 [ ] Region D"
Delete for a segment that is part of a non-contiguous (named) region would 
open a dialog asking, whether the entire region is to be deleted, or only the 
current segment.

> > Is there a way to trim this down any further? Perhaps the "Run block..."
> > action (with the dialog) could be shown automatically, whenever there are
> > several block around the current cursor position, and only then.
>
> An idea is to allow the user to define the current block and run it by
> default (given that I don't think that they will switch that much between
> current blocks during development), as well as allow her/him to make
> current the one containing the cursor or to select it at runtime.

OTOH, I think it's fairly reasonable to assume the current block of interest 
will also always contain the cursor. After all, it's probably, where you last 
edited something. Then there would not be much of a need for further actions 
like "set active block", "run active block" (vs. the one with the 
cursor), "run specified block" etc.

Perhaps this can be aided by highlighting the lines. Only the currently active 
region (i.e. the one with the cursor) would be highlighted (and all further 
regions belonging to the same block). Highlighting would be updated whenever 
the cursor moves to a different line.

I guess the highlighting is really something to experiment with, though. I 
suggest you simply try something (or set it aside until later), then we can 
see, whether it's a good solution or not.

> I never used Kate's API, so it'll take a while until I get to a solution...

Take your time.

> Ok, if nothing happens by Tue, let's have a spec and I'll start working on
> it (but it will take a while, as my time is rather limited at the moment
> :( ).

Well, we don't exactly have a specification, I'd say, but do you think our 
discussion is conclusive enough to base an initial implementation on?

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/20070306/5ad969f9/attachment.sig>